Quoting Stephen Smalley ([EMAIL PROTECTED]): > 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,
Yes, though since we're completely out of caps I expect 64-bit caps are now just around the corner. > and increasingly less > forward compatible with future extensions. Serge? As James suggested, I intend to at least implement compile-time configurable, maybe boot-time configurable ability to ignore unknown caps. Of course there is still the question of version numbers... I don't want to ignore changes in those, and i expect adding a cap will usually involve bumping the version number. But that's not at the top of my to-do list. (unfortunately - it's more fun than things which are higher) -serge - 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
