On 2-Jul-08, at 10:42 AM, Garrett D'Amore wrote: > 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)?
when run with per-user socket directory, the format that screen dumps sockets in to .screen is something to the effect of <pid>.pts-<pts #>.<hostname> which I think ought to be enough specifics that screen is unlikely to create the same file at the same time twice. I think that this is the preferable solution over the others that have been mentioned > 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.
