posix mac

[Ilmar S. Habibulin]

On Wed, 28 Apr 1999, Casey Schaufler 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.
My point of view is based not only on BLM, but its' predecessor -
sensitive(confidential) information processing methods. According to
these methods i'm building my implementation. BLM is only a formal model
which can be used to prove something.

> > 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.
Ok, i know it. But you must understand, that L2 can't be greater that
users max level. I think that these label should be equal.

> > 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.
I don't understand such concept. Try to explain more detailed please.
Maybe there is other models, that would protect agains possible
vulnerabilities - Biba model?

> > 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. 
Ok, and what would you say about 0, 1 and 2 file descriptors? What will
happen if i close them? Interactive process can't close these descriptors,
i suppose. So, according to your thesis, process will never raise its
level.
Now about write ops. Write-downs are impossible if you control _all_ write
ops(write, writev, send(it?) and svipc write ops). I just looked through
draft and found no references to any of write functions. Maybe i just
don't understand the rulez of the game?

> It is never OKay to lower the MAC label.
I think that it is an issue. MAC changes information processing methods
very much (from ussual DAC). And i just don't understand how to process
information, using your concept, in typical UNIX system. I can explain my
thoughts about lowering MAC label, if you are intersted. But first please
describe me how you will process information of different labels from the
users' process point of view.

> > 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's this? Can i find there info about 'bad experiance'?

> > 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.
Ok.

> 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).
Ok, how could system determine peers label in datagram communications? ;-)
If it can't - should it send sensitive info over network or not? If we
have trusted network thats ok. But if not?

> 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.
Its not an easy thing to mark all system buffers with label. :( And it
should be done.

> For a connection based communication, there must be a dialog, hence the
> label must be equal.
You mean dialog between peers or what?

> > 
> >                      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.
I don't understand what 'MAC enforcing X server' is, but just imagine that
i have two apps - text editor and some configuration tool with gui. I'm
processing some label L file with text editor and changing some config
with config.tool. So i will got config file label with L?

> > 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.
That is true only if we have some static labels. The thing is that i don't
understand how to use them.

> > 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.
I understand. Intersting food for thoughts.

> > 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.
Why should i. ;-)

> 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
Ok, i undertand that capabilities are great stuff. I'll read about them.

> 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.
???

My own concept is to consider root as pseudo-user, and root services are
user-level(app-level) extentions of kernel.

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message