Date: Tue, 12 Dec 2017 19:01:06 +0100 From: Salvatore Mesoraca <s.mesoraca16@...il.com> To: Solar Designer <solar@...nwall.com> Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>, Matthew Wilcox <willy@...radead.org> Subject: Re: [PATCH v3 0/2] Restrict dangerous open in sticky directories 2017-12-11 17:07 GMT+01:00 Solar Designer <solar@...nwall.com>: > On Thu, Dec 07, 2017 at 11:23:34PM +0100, Solar Designer wrote: > > On Tue, Dec 05, 2017 at 11:13:50AM +0100, Salvatore Mesoraca wrote: > > > 2017-11-30 20:05 GMT+01:00 Solar Designer <solar@...nwall.com>: > > > > A new thought: a directory that has someone else as its owner is for our > > > > purposes effectively the same as a group-writable directory. So maybe > > > > whatever we'll implement for group-writable directories should also be > > > > done for directories that have other than the current fsuid as their > > > > owner. It's currently very uncommon to have directories with the sticky > > > > bit set that are not at least group-writable, so this will rarely make a > > > > difference (and when it does, that's just right), but also it provides a > > > > way to explicitly include any dibrectory under this monitoring (if the > > > > group-writable protection is on) - e.g., if a sysadmin wants this > > > > monitoring for users' home directories, they can change permissions for > > > > those from e.g. 700 to 1700. This could be handy for development and > > > > auditing of software, even though in production it could be easily > > > > circumvented by the directory owner (who can remove the sticky bit, > > > > which we should document to avoid providing a false sense of security) > > > > and it won't automatically apply to subdirectories. It'd also cover > > > > part of what we intend to achieve later by possibly extending the > > > > feature to non-sticky directories, where we might also want to treat > > > > different owner the same as group-writable (without the circumvention). > > > > > > Agreed. I'll extend it to also check for the directory owner. > > > Maybe I could use another bit and make this additional restriction > > > independent from the "group-writable" one. > > > > I'd prefer not to waste a bit on this. We'll need plenty of bits later > > on, perhaps also in pairs or (with your suggestion to separate this one) > > in triplets, and every extra bit complicates the calculation of the > > bitmask value. > > OTOH, if we were to interleave the world and group bits, then maybe > instead of having the world and group bits as separate we could have a > two bit number, which naturally leaves us an extra value we'd use for > owner. So: > > 0 - none > 1 - world > 2 - group and world > 3 - owner, group, and world > > This would remove the ability to enable our restrictions for group (and > owner) while disabling them for world, but that's likely just an obscure > misconfiguration. > > Unfortunately, this is not compatible with my other idea of easily > extending a tested policy from world onto group by simply assigning the > same value to the other sysctl. > > I'm not sure which of these approaches is cleaner. I prefer the version with separate sysctls for world/group, it seems more usable. Salvatore
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.