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

[John Sonnenschein]

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