On Wed, 2007-07-18 at 20:46 -0700, Casey Schaufler wrote: > --- Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-07-17 at 19:59 -0700, Casey Schaufler wrote: > > > > > - Speaking of which, are you ok with your MAC model being overridden > > > > > by > > > > > all uid 0 processes? Or do you plan to change securebits and use file > > > > > caps? > > > > > > I've been tracking the file caps closely. I like file capabilities, > > > but I have had success with uid 0 MAC systems as well. Long term, yes > > > I want file caps, but the uid 0 world is important, too. > > > > So uid == 0 is still all powerful with your module, right? > > No restrictions on any uid 0 process, not only for authenticated root > > shells but for any system process running with uid 0 or any setuid root > > program. They can override your MAC model at will, as well as > > indirectly subvert it via other capabilities. Whereas most (all?) other > > security modules to date allow you to restrict what capabilities can be > > exercised by a uid 0 process. > > Smack is intended to be a MAC module. I want to leave the privilege > model as an independent issue.
It can be a separate mechanism, but there is a dependency there naturally (for protection of the MAC model). > > > > Other question there is if you aren't going to recheck on use, then what > > > > story do you tell wrt relabeling of files and/or tasks changing labels, > > > > given that you permit both to happen? > > > > > > It requires privilege. Really, that's the answer that's been used > > > on every B1/LSPP evaluation up until yours (Congratulations, BTW) > > > and an important aspect of the system is that labels don't change > > > very often, and only under controlled circumstances. > > > > The "labels don't change very often" bit is a good principle, albeit > > hard to achieve in an imperfect world. > > I think that the smack rules model will be helpful there, although > it will bring up issues of it's own. Hey, that's the selinux way of thinking - change the rules, not the label. The label describes the data (security properties thereof) and doesn't need to change. > > The "under controlled > > circumstances" seems hard to guarantee since to change task or file > > labels at all in your model, you are required to have complete > > MAC_OVERRIDE anyway, so there are no restrictions from a MAC point of > > view at all, and you have no other mechanism to protect and limit the > > process, other than DAC, which is fairly weak in its ability to provide > > such guarantees. > > That's an argument in favor of a fine grain privilege mechanism. > MAC_OVERRIDE is likely too coarse, where a capabilty for each > individual check is likely finer than is helpful. > > > That's one of the benefits of TE, being able to > > protect and limit MLS trusted subjects more effectively. > > If you like that level of granularity it's hard to argue > that TE is a poor choice. It does let you apply MAC overrides at the granularity not only of per-operation but per-object/label (i.e. trusted downgrader can downgrade these objects but not those objects, and can further only downgrade from X to Y), as well as help protect the integrity of the trusted subject. BTW, do you envision using this mechanism to express composite BLP+Biba simultaneously? If not, what's the plan for an integrity mechanism to complement BLP? > > There is no locking evident in the patch at all, either for your global > > data (e.g. smack_list, smk_links) or for your per-object security blobs > > (e.g. look at how selinux does locking for setup of the superblock and > > inode security blobs). > > I'm having a look through the locking. I don't think it has to > be as extensive as SELinux. Fewer lists to deal with. Not sure it really differs substantially aside from the fact that you don't have any security decision cache (AVC). > > Also make sure you don't re-init your inode > > security blob in d_instantiate after having already set it up once. > > The inode security blob is a single smack_t. Yup, that's still larger than a word (which is a nice property of the SELinux SIDs for manipulation), and you still don't want to clobber it once it has been set (you don't want a subsequent d_instantiate on the same inode to replace the smack label once it has been set; you don't want to clobber a previous setxattr with a re-init for e.g. your devpts labels). > > You'll eventually have to broach the issue of getting your own > > capability bit rather than reusing an existing one. > > When the expanded capability set goes in and bits become > available the whole if and if so how many discussion awaits. Sorry, what expanded capability set? File capabilities patch was still limited to 32 bit capabilities last I looked, and increasingly less forward compatible with future extensions. Serge? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
