Considering all you've mentioned, I think the best and least hack-ish solution might be to deliver with --disable-socket-dir , which ( true to it's name ) disables the system socket dir, using the user's ~/.screen instead
On 2-Jul-08, at 2:59 AM, Brian Ruthven - Sun UK wrote: > [ Please forgive my intrusion - if it's not my place to comment on > this, please reply to me directly rather than polluting the PSARC > mail log with education hints for me :-) ] > > I am using the setuid-installed screen 4.0.2, and if a regular user > can create something called /tmp/screens before the first invocation > of screen, then screen complains (probably quite correctly) with > something like "Directory '/tmp/screens' must be owned by root." or > "'/tmp/screens' must be a directory." > > However, this seems like a very simple DoS attack to me. It's > obvious what the problem is (thankfully, the error messages are > meaningful), but still requires manual intervention to fix the > problem. What steps could be taken to prevent this? (if it is even > worth preventing in the first place) > > I'll offer the following for consideration: > Could the socket dir be located under, e.g. /var/run instead? > I hesitantly also suggest a new tmpfs filesystem, something > like /var/screens. > The solution of Solaris creating the directory every bootup > seems like a bit of a hack to me, but I'll mention it anyway :-) > > Brian > > > Nicolas Williams wrote: >> >> On Tue, Jul 01, 2008 at 01:26:14PM -0500, Nicolas Williams wrote: >> >>> | - 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/. >>> >> FWIW, the screen delivered by the Solaris CCD: >> >> - is not setuid/setgid >> - does not use PAM >> - it gets the load averages just fine, even though it's not setuid >> >> Provided that you disable PAM support in screen and ship it not >> setuid/setgid, then the only security issue relates to the path where >> screen puts its sockets (see my previous post about that). >> >> Nico >> > > -- > Brian Ruthven Sun > Microsystems UK > Solaris Revenue Product Engineering Tel: +44 (0)1252 422 > 312 > Sparc House, Guillemont Park, Camberley, GU17 9QG
