Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRe: [patch 0/2] policy capability support
From: Joshua Brindle <method_at_manicmethod.com>
Date: Wed, 05 Dec 2007 15:56:59 -0500
> On Wed, 2007-12-05 at 15:35 -0500, Joshua Brindle wrote: > >> Stephen Smalley wrote: >> >>> On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote: >>> >>> >>>> Stephen Smalley wrote: >>>> >>>> >>>>> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote: >>>>> >>>>> >>>>>> Paul Moore wrote: >>>>>> >>>>>> >>>>>>> The discussion for this appears to have gone quiet (at least I >>>>>>> haven't seen anything else on this list). Where do things currently >>>>>>> stand? >>>>>>> >>>>>>> >>>>>> At this point I'd be OK with requiring equivalence and throwing an error >>>>>> otherwise. I do think that this will result in usability issues that we >>>>>> will have to address once people start using the caps. However, with >>>>>> only >>>>>> a single cap defined so far it is not really possible to know how these >>>>>> will end up being used. >>>>>> >>>>>> >>>>> We could try to come up with a solution at least for allowing clean >>>>> upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) >>>>> without requiring manual user intervention for dealing with local >>>>> modules. >>>>> >>>>> >>>>> >>>> This was my exact objection to using an intersection or equivalence. IMO >>>> it is incompatible to require all modules to be the same and to also >>>> require upgrades to work without manual intervention. >>>> >>>> Do you still think unioning is wrong? >>>> >>>> >>> Yes, I'm still against (automatic, default) unioning of the capabilities >>> by the linker - that is clearly not a safe default. semodule could >>> possibly override that behavior based on an option though, at which >>> point the %post scriptlet in the policy rpm could use that option if we >>> wanted to force it w/o user intervention. >>>strange semantics anyway since it isn't clear which set of caps would end up in the kernel policy) we could have an --upgrade-polcaps option that unions the bitmaps of the modules installed. It isn't pretty but it requires manual intervention to union them instead of doing so automatically. This obviously will break local policies that do not support the cap but need to. The user will have to figure out how to update those local policies to add the required permissions, this isn't any different than adding new permission checks to the kernel though. I'm still concerned about audit2allow's ability to decide what caps to put in a policy module being generated. I also have concerns about new policy modules that are being written by hand, the users aren't going to necessarily know what caps are available and why they should care. I'm sure SLIDE will be able to take care of that though ;) -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.Received on Wed 5 Dec 2007 - 15:57:14 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |