posix mac

[Casey Schaufler]

Sorry about the slow turn-around on this response. To make up for it,
I'll
try to be as complete as I can.

Ilmar S. Habibulin wrote:

> User have some access level, which describes max level of sensivity of
> information that user can read/write.

Each user should have a set of MAC labels which she can use.
This could be described as a list, a range, or a list of ranges.
Under Trusted Irix this is kept in /etc/clearance.

> But we can't use this level as
> starting point for applaying MAC rulez. Because if we will do it, user
> will work only in its' max level or will have uncontrolled access to
> write operations. So he can write sensitive data as non-sensitive.

To satisfy Bell & LaPadula, all information created by a process which
can
read label L1 must be written at a label which dominates (is greater
than
or equal to) L1.

> Because of that i have second level, which is called current. At the very
> beginning user have current level equal to system low.

Users should never be allowed to use system low. System low should be
lower than user low, to protect the system processes from user data. On
Trix, these labels are called dblow and userlow, respectively.
 
> His current level may be encreased while work to the value of his max level.

It's only OKay to raise the MAC label if all open file descriptors are
closed,
SVIPC objects disconnected, and so forth. If they are left open it is
possible
to do write-downs. It is never OKay to lower the MAC label.

> So we have floating levels.

Advocating floating labels is not a good idea. The security community
has
had a very bad experiance with floating labels as defined in the CMW
specification.

> what do you say about
> possibility of writing to the socket from different processes which have
> different current level? What level should socket have? Or how would
> change current level of recieving process or processes?

Let's consider datagram and connection based communications seperately.

For a datagram, a send operation is a blind write, for which the sender
receives no feedback with regard to it's success or failure. Thus, the
system could deliver a datagram to a socket associated with any process
which is has a MAC label (Lr) which dominates that associated with the
datagram (Ld). The correct value for Ld is the Mac label of the sender
(Ls).
Let us be careful, however. In almost all cases, there will be a reply
which must follow the same label restrictions. The only case where this
is
true will be where Ls and Lr dominate each other, which is the equality
case.

For a connection based communication, there must be a dialog, hence the
label must be equal.

> 
>                      X Server
>                    ^|       |^
>                    ||       ||
>                    ||       ||
>               --1--+|       |+--3----
>   X Client A        |       |         X Client B
>               <-2---+       +---4--->
> 
> Let's consider that when process recieves some classified data from socket
> its current level increases. So it can't recieve unclassified data.

Clients A and B above must be at the same MAC label as the server,
unless
you're willing to have the server enforce MAC. CMW systems have MAC
enforcing
X servers.

> > > Sources are commercial secret? ;-)
> > So far, but you never know ....
> Sorry, i don't understand what are you saying.

To date, they haven't been open sourced.

> And maybe FreeBSD? ;-) Do they have B1 systems? And they are sertified?

I'm not sure about the state of FreeBSD, although some believe it's
further along. And no, they're not evaluated.

> Every newly created object gets current MAC level of their creators. But
> shared memory and mmap have uncontrolled posibilities of write operations.

These objects need to require write access (MAC equal) to open for read
because although they seem like they ought to be available read-only,
they
are in fact not.


> Device is labeled with one level. And i'm using current process level for
> checking.

That's correct.

> ??? What to do? What do you mean by word 'upgrade' - encrease dir label?

Upgrade means to change the MAC label to a new value which dominates the
old.

> What users data??? I thougth that auditor must have access to all logged
> info. I'm wrong?

No, you're right. The issue is that if I made the audit info system high
the auditor would have MAC read access to all the files on the system.

> One more question: should root(0) obey MAC rulez?

This is one of my favorite topics, but I'll try to limit myself so you
don't get bored.

In a system that uses capabilities, root can and should be an
unprivileged
user. In this case the answer in yes, and appropriate capabilities
should
be defined for MAC, perhaps

	CAP_MAC_READ
	CAP_MAC_WRITE
	CAP_MAC_RELABEL_OPEN
	CAP_MAC_RELABEL_SUBJ

In Trix 4.0.5 (the version we evaluated) root was never allowed to
violate
the MAC read policy, but was allowed to violate the MAC write policy if
and
only if the process was running at system high. This allows the
Superuser to
"push" down, but not to "pull" down.

-- 

Casey Schaufler                         voice: (650) 933-1634
casey at sgi.com                           fax:   (650) 933-0170
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message