On Sun, 26 Mar 2006, Elad Efrat wrote:

>> i don't think "tcb" is a good idea because some aspects of securelevel have 
>> more appropriate scopes.  and we already have "generic" scope for misc 
>> operations.
>
> Yes, but I'm not sure these are "misc. operations"..
>
> I'll give you two examples of operations: the first, is checking if process 
> A can "look into" process B. We use this check for things like filtering ps 
> and netstat output per-user. The second operation is "can this process 
> attach systrace to init". Obviously, this is a process related operation, 
> because the very act of attaching systrace (or ptrace, for that matter) 
> belongs -- clearly -- in the process scope.
>
> However, I was suggesting a different point of view: there *is* a difference 
> between these two operations, the difference that justified the creation of 
> securelevel. While the first operation can cause little harm to the system 
> (so what if joeblow gets to see root owned processes?), the second operation 
> suggests that joeblow (or a compromised root) could attach to init, 
> manipulating it, compromising the TCB.

I've followed the kauth design process at Apple, and the NetBSD discussions 
along these topics with interest, having gone through much the same process in 
the integrating of mandatory access control and ACLs into FreeBSD a few years 
ago.  I thought I'd share a few thoughts, which you're welcome to ignore. :-)

The problem of categorizing checks is actually quite difficult -- in the 
TrustedBSD MAC Framework in FreeBSD, we end up avoiding the issue by not 
categorizing access control checks at all, but loosely naming them based on 
the "object" of the operation.  LSM takes a very similar approach.  The Darwin 
kauth framework has been influenced by the MAC Framework design, but takes a 
more explicit approach to categorization.  I've always liked the notion that 
we categorize operations, and checks more specifically, by the object type. 
This is made tricky when you have checks that involve multiple objects without 
an explicit subject, however.  For example, the check to deliver an mbuf to a 
socket in FreeBSD is a subject-free operation.  In the end, all this comes 
down to is the ease of grasp of the framework for the developer, and the ease 
with which they can express the policy they want to implement.  The 
object-oriented view of the world is useful, though, and thinking about it as 
objects and methods is a useful way to think about things.

kauth(9) is an interesting framework, and clearly benefits from a lot of the 
prior work, be it FLASK, LSM, the MAC Framework, etc.  It's a carefully 
selected subset intended to support Apple's critical audiences -- workstation 
firewall vendors, anti-virus vendors, the need to introduce ACLs, etc.  It 
doesn't meet the full set of needs we have in FreeBSD -- for example, it does 
not provide clear object life cycles and labeling facilities required for 
mandatory access control.  One of the design choices in kauth(9) is to provide 
relatively few methods for the security module to implement -- this is helpful 
in some ways, and makes it easier to implement variant logic using switch(), 
etc, but makes other things trickier.  In FreeBSD, we originally went a bit 
more in this direction, but then moved away because we were concerned about 
proiding stronger type safety for policy implementors -- we ran into a lot of 
bugs where the void arguments for generic check functions were being miscast, 
especially as the APIs evolved.  When we switched from a smaller number of 
indexed checks to a larger number of function prototypes with explicit type 
checking, these went away.

Robert N M Watson