GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008]

[John Sonnenschein]

Fair enough

so for this case it shall be built without --enable-pam, and users are  
responsible for their own passwords through ~/.screenrc . We may wish  
to revisit this decision in the future when a better analysis of  
security best-practice with respect to screen can be done

On 1-Jul-08, at 11:26 AM, Nicolas Williams wrote:

> On Tue, Jul 01, 2008 at 10:32:49AM -0700, Darren J Moffat wrote:
>>   Imported Interfaces
>>
>>   Interface                         Classification     Comments
>>    
>> -------------------------------------------------------------------------
>>   There's no imported interfaces worth mentioning.
>
> Privately I'm told screen would be built with --enable-pam.  But that
> would imply that screen should be setuid-0 or to be executed with
> privileges via pfexec.  That's because on Solaris PAM requires all
> [zone] privilege.
>
> screen built with --enable-pam uses PAM to authenticate users  
> attaching
> to detached screen sessions.  This is unnecessary, since file
> permissions are sufficient to ensure that the client attaching is
> authorized to attach.  Besides being unnecessary it's also problematic
> (see above).
>
> Also, screen supports the use of crypted passwords in ~/.screenrc to
> provide for additional authentication where desired -- that clearly  
> adds
> very little protection, since a process running with the same euid as
> screen and not lacking PRIV_PROC_SESSION could always trace/debug  
> screen
> to allow the attach.  But this is not objectionable.
>
> So I strongly urge the i-team to not enable PAM support in screen.
>
> Finally, I think we really need to know if screen will be setuid-0.   
> The
> INSTALL file in the distribution says:
>
> | Consider this, when deciding whether you install screen setuid-root:
> | - On some machines root privileges are required to open pty's.
>
> Not on Solaris.
>
> | - Pty's should be owned by the user, so that she can do chmod to  
> prevent
> |   intruder attacks. The PTYs used by screen will remain world read- 
> writable
> |   if screen is not installed setuid-root.
>
> grantpt(3C) ensures that ptys are owned by the user.  I see screen  
> knows
> to use grantpt(3C).
>
> | - Some commands only work properly when the pty is owned by the  
> user.
> |   These include mesg and biff.
>
> N/A (see above).
>
> | - The ^At feature may need to lseek and read the kernel file to  
> retrieve
> |   the load average.
>
> Wouldn't work on zones.  I've not looked at whether screen knows  
> better
> ways to do this now, but I really don't mind if this doesn't work.
>
> | - On most machines utmp slots can only be created/manipulated with  
> root
> |   privileges. Users will appear to be logged on the primary terminal
> |   instead of the screen windows, if screen is not installed setuid- 
> root.
>
> I'm not sure what the deal is with this in Solaris.  But I also don't
> care if I can't use w(1) to see what I'm doing in each screen window.
>
> | - Multi-user screen sessions are only allowed when screen has a
> |   root-s-bit.
>
> I'm not sure why that would be true, but, I don't mind this either.
>
> For this we could always have an RBAC profile if this feature really
> must be there and if it can only be implemented by giving screen
> privileges (which ones?).
>
> | - If screen sockets of multiple users are kept in one directory  
> (e.g.
> |   /tmp/screens), this directory must be world writable when screen  
> is not
> |   installed setuid-root. Any user can remove or abuse any socket  
> then.
>
> On my system screen (from the Solaris CCD) keeps its sockets in
> /tmp/uscreens/S-$USER/.
>
> This strikes me as wrong (/tmp/uscreens is owned by the user running  
> the
> first instance of screen to run since boot, and it's 777, no sticky  
> bit
> set).
>
> screen should use /tmp/S-$USER, or better, $TMPDIR/S-$USER, which  
> leaves
> the problem of creating a suitable directory to the login system.
>
> Nico
> --