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 > --
