Date: Tue, 15 Mar 2011 18:36:05 -0600 From: RB <aoz.syn@...il.com> To: owl-dev@...ts.openwall.com Subject: Re: tcpdump vagaries On Tue, Mar 15, 2011 at 17:07, Solar Designer <solar@...nwall.com> wrote: > One of my concerns is that if the sniffer is to create additional files > after dropping root, the directory holding those files will need to be > writable by the non-root pseudo-user. Whether or not it's writable, where tcpdump falls down in this case is that it doesn't make that check early enough. If the first file were created after dropping privileges (as opposed to after), this wouldn't be an issue, as the user immediately gets feedback that the file cannot be created. This encroaches on bug territory, and I'll have to see what the progress is on accepting Dmitry's (and any similar) patch. > Yet those files would then be > examined by root, which allows for certain attacks (via (sym)links to > device files, etc.) I'm not sure what you're suggesting here; beyond the privileges to capture the packets, no elevated ones would (or should) be required to analyze the resultant files, as long as the user has proper group membership. > I'm afraid there's no perfect solution to this, > although we might try to do "something" - e.g., have the sniffer create > the subdirectory prior to dropping root, set perms to 1730 with the > pseudo-user's group, and our kernel is to be hardened again to distrust > symlinks in +t directories like 2.4.x-ow kernels were. Perhaps; I personally think digging too far into the potential failure cases takes away from allowing the administrator to make precise choices and tends to make software excessively complex. As long as privileges are dropped as early as possible, particularly prior to file creation, it should be up to the user to solve any permissions problems that arise.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ