--- 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. > > > 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. > 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. > > Updated patch: > > > > http://www.schaufler-ca.com/data/smack-0717A-patch.tar > > Ultimately, you have to actually post the patches inline if you want > more extensive comments and/or to actually submit anything. Yes, I plan to do that for the next go and see how loudly the community complains. > Don't forget to follow the guidance in Documentation/SubmitChecklist and > run scripts/checkpatch.pl on it. And check it via sparse. Yup. > 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. > 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. > 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. > Obviously those key hooks need to be filled in (or dropped). Yes. Thank you again. Casey Schaufler [EMAIL PROTECTED] - 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
