Re: MAC

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: MAC
Date: 16 Apr 1999 09:31:00 +0200
Next Article (by Date): RSBAC 1.0.8 for Linux Kernel 2.2.5 ao@morpork.shnet.org (A. Ott)
Previous Article (by Date): Last call for reports ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: MAC Stewart Robert Hinsley
Articles sorted by: [Date] [Author] [Subject]
********* ***************** ********** ****  *****   ***** ************
  To Subject Re: MAC
  Stewart wrote:
********** ******************** ******  ********  ******* *************

> Perhaps you should redirect responses to my emails to the list.

Done. :)

> PS: I can't get through to the Pretty Secure Linux web pages. Could you give
> me an email contact address please.

They may be down. I haven't heard of Vadim for months now.

> >Well, yes. There are loads of covert channels of the same style in a Linux
> >system, most of which are difficult to address. And there are no name
> >spaces.
>
> IIRC, there's 3 channels which have to be addressed; public shared
> directories (the /tmp you mention below), System V IPC namespaces, and file
> locking. There might be more that I forget, or which are new to Linux.
> Namespace channels in general have to be closed, so there might be one
> related to, say, sockets.

These are three main groups. As all shared resources as well as exclusive  
resources can be used as covert channels, there is much more to do. Think  
of device access (floppy, tape). You already mentioned sockets.

And think of another host, being used for data transfer. We would have to  
build a trusted network with name spaces or reduce network access to one  
name space or level public only.

> In general resource measurement and resource exhaustion channels don't have
> to be fixed at B1, though it may well be necessary to control access to any
> kernel data which is shared between processes. A technique for handling
> resource measurement channels is to generate random, rather than sequential,
> IDs, e.g. for processes.

OK, random IDs are not that difficult, though generation is probably a bit  
slower than now.

> >> This problem can be addressed by making the object MAC label part of the
> >> name space, which requires a read-equal policy.
> >
> >Read-equal is easy, but separate name spaces are hard. Maybe we find a way
> >to implement them together.
>
> A partitioned name space, where each MAC label corresponds to a partition,
> is feasible. All that is necessary is that when searching for a key
> (shmget(), etc) or id (shmat(), shmdt(), etc) is that the code checks that
> the subject MAC label equals the object MAC label as well as the key or id
> matching. This enforces a read-equal/write-equal policy, as a process cannot
> see an IPC object with a different label.

Or, in my terms, a read/write/append open on target IPC is checked. This  
already happens, but not yet as read-equal.

> >                          Before that we should find a solution for the
> >/tmp dir problem, which is much worse - a filename has full 256 Byte and
> >is easy to be read, if you have /tmp access. Separate /tmp dirs for each
> >seclevel *and* for each compartment are one possible solution.
>
> That's the standard solution for /tmp, etc. It's called multilevel or
> partitioned directories, and it's in POSIX .6. IIRC, it doesn't work well
> with RFS[1] (or with any f/s which processes more that one level of
> directory per call to VOP_LOOKUP(); however this problem may be specific to
> the SVR4.0 VFS mechanism) - I forget whether the problem was with multi-
> level directories, symbolic links, or the combination.

And now we come to the 'change current level/compartment set' area: What  
shall we do then? Force a close on all open /tmp files? This would break  
many programs, although the level/comp changing is limited with open files  
anyway.

Not RSBAC/MAC aware programs are currently handled by an automatic  
mechanism. This would have to take all the name space problems into  
account.

Another problem: MAC is only one of many models. The other models might  
not be pleased, if the MAC module changes name spaces underneath them.

Amon.

--
-
To unsubscribe from the rsbac list, send a mail to
majordomo@morpork.shnet.org with
unsubscribe rsbac
as single line in the body.
Go to Compuniverse LWGate Home Page.