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