posix mac

[Ilmar S. Habibulin]

On Wed, 14 Apr 1999, Casey Schaufler wrote:

> > Yes, that is nice idea. I don't know what is the starting point for posix
> > standards,
> It was SVR3, with heavy input from a little school near Oakland.
Wow. ;-) Can't you take an older release. just kidding.

> http://www.tsig.org if you missed it.
No, i've been there. ;-)

> > But at this point i think, that we should better limit
> > network communications in the way that only unclassified persons
> > (processes) can make network connections.
> I'm not sure what you mean here. It is very important that network
> connections enforce the system security policies, including MAC.
Sorry guys. Sometimes it's difficult for me to explain my thoughts and
understand your letters. But i'm trying.

> That pretty well requires that some mechanism be put in place to
> propogate security attributes (uids, MAC, capabilities, ...) along
> with network communications. The TSIX (from TSIG) scheme does this,
> as does IPSEC. I suggest that IPSEC is the future, and that that be
> the scheme which is used unless it proves fatally flawed.
My thought about sockets and MAC label - process, which wants to make
network connection must have MAC label equal to System Low(am i right?).
You ask me why? Because, if we will look at such complex thing as Desktop
Environments in X Window System, we will saw a huge amount of network
operations. Now we put MAC rules on them. So what we have? If processes
are communicating with each other - that's ok. But if processes are
communicating with some server process, like X Server - it becomes a
problem. I had undetermined crashes while trying to implement MAC over
network connections. So, process credits/auth info/crypt keys/etc - maybe
passed and used by network layer. MAC can't. That's my point. 
Agreed?

> > > POSIX.1e provides a good starting point and guidance: I personally don't
> > I'm agree with that. But people worked hard for several years. Are they
> > here? Can we discuss our problems?
> I was technical editor on the POSIX draft for the last three years,
I know that.

> and was involved wit hit from the beginning. I have also implemented
> MAC twice (Sun and SGI) and maintained it for the past ten years.
> I am happy to discuss any issues, as my time allows.
Sources are commercial secret? ;-)
I think you know my questions. Files/processes are simple abstractions.
What to do with sockets/sysv ipc/etc(not mentioned).

> > Ok, lets forget about decrement rule. But we've got missed _uncontroled_
> > objects. They are sockets and SysV IPCs.
> Sockets can be addressed per TSIG and/or IPSEC.
It's another standard. And i just don't figure out what TSIG is. Some inet
group or what?

> SysV IPC objects are simple if you adopt a policy that all accesses
> require write access. This is true for semiphores and message queues,
> and close enough for shared memory as to not matter.
Oh. Shared memory is a verry dangerous thing. (and mmap too). For shared
memory i propose system low level, and for mmap - system low only for
writing.

> > And i don't like that many things
> > are "implementation defined" or "unspecified".
> No one does. They are there because of the differences in vendor
> solutions to problems "outside the scope" of POSIX. Examples:
> 
> 	/dev/null
> 	/dev/tty
My implementation is - label of device represents max sensivity label of
data, that can be passed through device. Like it?

> 	/tmp
Directories - very interesting files. I had to move them to "special
group", not like ordinary files. So you can have access to directory and
its content if you have appropriate access label. But this directories can
hold files of any label. So /tmp - System High. ;-)

> 	what label to give audit trails
I think it's admins job to think about it. Or i just got something wrong?

> 	what label to give system data
What is system data? I think that inside system(kernel) data shouldn't
have any MAC restrictions, only MAC labels. Or i'm wrong again?

> 	how to represent "System High"
It's the higest MAC label in the system?

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