some questions (Re: mac-0.5.diff)

[Ilmar S. Habibulin]

On Thu, 4 Oct 2001, Robert Watson wrote:

> 
> On Fri, 28 Sep 2001, Ilmar S. Habibulin wrote:
> 
> > > Right now enforcement of MAC policies on files is done inside the UFS
> > > implementation, and within procfs, so isn't implemented for devfs, or NFS
> > > (or others).  I have some initial patches that provide generic
> > > single-level labeling support for file systems that don't support MAC, and
> > > hope to get that into the next patch.  It involves expanding the use of
> > > vaccess() a bit so that the vfs mount is passed in for the vnode when a
> > > decision is made, so that the mount label is available.  We probably also
> > > need a VFS call to change the mount label (right now the default is to
> > > copy the label from the credential authorizing the mount operation) --
> > > perhaps vfs_relabel().
> 
> > Take a look at my old work. I have a higher level access control code,
> > which intercepts system calls and makes decision based on
> > subject(process)  and object(file,socket,pipe,ipc,etc) labels. So in FS
> > case - if FS support labels, it will provide access control mechanism
> > with the current label of the file, or if not - the label of file would
> > be some default label. So you need not to hack every FS code to make MAC
> > hooks there. Just teach FS to import/export labels and that's all.
> 
> I've thought some about this approach, although had some worries about
> compound operations that occur in individual filesystems.  Another concern
> is that vn_rdwr() is frequently not used in kern_*, instead, VOP_WRITE()
> or VOP_READ().  Fixing that might be a good idea and make the task easier.
O-ho-ho. You are digging too low imho. I think that MAC should be
implemented at a higher system level. I've inserted hooks in
read()/write() syscalls. So i do no care about any fs-specific operations.
I just grant or deny operation itself. The main problem is to get label
from objects of different kinds (file descriptors, vnodes, sockets and so
on). So if you are using such approach, then the logic of MAC became much
more clear and portable, because you have separate MAC granting/denying
access functions and label retrieving/storing functions(they can be
system/object specific).
Another my thought is - that approach is good not only for MAC, but for
DAC too. So objects must import/export security attributes, and control
mechanism just make a dessision to grant or deny access. This is the
reference monitor, described in orange book. Implementing such monitor
makes developing, debugging and testing much more easier.
Everything is IMHO.
Think about it.

> Is the tarball on your fledge home directory the code you're referring to?
No, i mean mac-0.3 from trustedbsd download page. There is only one
limitation - sockets are blocked. This code is my basis for developing
packet labeling.


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message