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. > > 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. 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 one of the benefits of TE, being able to protect and limit MLS trusted subjects more effectively. > 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. Don't forget to follow the guidance in Documentation/SubmitChecklist and run scripts/checkpatch.pl on it. And check it via sparse. 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). Also make sure you don't re-init your inode security blob in d_instantiate after having already set it up once. You'll eventually have to broach the issue of getting your own capability bit rather than reusing an existing one. Obviously those key hooks need to be filled in (or dropped). -- 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
