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

[Garrett D'Amore]

Nicolas Williams wrote:
> On Wed, Jul 02, 2008 at 10:59:03AM +0100, Brian Ruthven - Sun UK wrote:
>   
>> 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)
>>     
>
> We have this attack for lots of other things, sadly.
>
>   
>> 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 :-)
>>     
>
> IMO the correct solution is for a PAM module (pam_unix_session) to
> mktemp a user's TMPDIR the first time the user logs in since boot.  The
> module should record this TMPDIR so that the user gets the same TMPDIR
> on subsequent logins whenever possible (e.g., whenever the TMPDIR is
> still owned by the user).   The module should set that environment
> variable.
>
> And then screen could use $TMPDIR/screens as the socket dir.
>   

An interesting design with merit, but it sounds like something that has 
ramifications beyond this case, and would need to be run separately (a 
separate ARC case/fasttrack).

Meanwhile, if ~/.screens works, that sounds reasonable to me.  My only 
possible concern there is how this behaves over NFS.   John, will 
multiple screen sessions running on different machines with a shared NFS 
screens dir interfere with each other?  Are there any caveats (such as 
the hostname being required to be different)?

I will also point out, there is a different approach possible:  make a 
tiny wrapper program that checks/makes the screens dir (enforcing 
permissions), and then just execs the real screen program.  This could 
either be setuid program that then drops its permissions before execing 
"real-screen", or it could be a shell script that uses a setid helper 
program to make the screens dir.  Such an approach does represent more 
work (a little) for the project team, but it doesn't require any changes 
to the upstream sources, and could be done in the context of this case.

And FWIW, yes, I prefer /var/run to /tmp for this use, I think.

    -- Garrett
> Nico
>