On 31 May 2001, David Wagner wrote: > I'm still quite concerned about only supporting 'permissive' policies > (and not supporting 'restrictive' policies) for some actions. > > How does this affect the other projects? Do the SELinux folks want > to enforce 'restrictive' policies for any hooks that are currently > 'permissive'-only, for instance, or is everything fine as is? The SELinux module needs to be able to implement more restrictive policies for all of the hooks. In the setpriority example, we need to be able to prevent a process from setting the priority of another process even if it has the same Linux uid (e.g. if SELinux is being used with its Type Enforcement policy module, then the 'setsched' permission must be granted between the domains of the two processes, even if the uids are the same). In the original SELinux prototype (i.e. the one available at http://www.nsa.gov/selinux/download.html), we strictly implemented more restrictive controls, i.e. SELinux may deny permissions that would normally be granted but it cannot grant permissions that would normally be denied. Ideally, in the longer term, we would also like to be able to override denials in a similar manner to the capabilities model - See http://www.securecomputing.com/pdf/secureos.pdf for a discussion of how Type Enforcement compares with the POSIX Capability Model. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu May 31 2001 - 05:59:41 PDT