On Wed, Jul 29, 2009 at 9:32 AM, Stephen Smalley<sds@xxxxxxxxxxxxx> wrote: > If you want something more akin to privilege bracketing within a > program, then a closer analog in SELinux would be setcon(3) to switch to > a more restricted domain. But in general our goal is to enforce > security goals at the system level and not depend on the correctness of > the application to shed privilege. [snip] But then, of course, we depend on the correctness of the system to deny privileges. Considering the number of users that disable SELinux entirely— this surely can't be counted on. And the historic number of applications which fail to shed privilege (to the limited extents possible) shows that depending on the application also isn't a complete solution. It seems to me that the approaches could be complimentary— It would be very nice if applications could drop any SELinux controlled privileged at runtime, either temporarily or permanently. This would not replace the system level protection but would supplement it by remaining active even if the wider protection were partially disabled, by offering finer granularity, and by giving developers a greater opportunity to participate in the use of SELinux (perhaps resulting in more applications being structured in SELinux friendly ways). Capabilities are agreed to be far too coarse, and they only subset root when we really want to subset user permissions too. SELinux provides many nice hooks. Developers would like to right software that remains as secure as possible even if a user has goofed up the file permissions. Is there no possible improvement here? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
