Re: MAC

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: MAC
Date: 22 Apr 1999 11:08:00 +0200
Next Article (by Subject): Re: MAC Stewart Robert Hinsley
Previous Article (by Subject): Re: MAC Stewart Robert Hinsley
Top of Thread: Re: MAC 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@meden.demon.co.uk (Stewart Robert Hinsley)  wrote:
********** ******************** ******  ********  ******* *************

> In message <7EzQKBi$4iB@ao.morpork.shnet.org>, "A. Ott"
> <ao@morpork.shnet.org> writes
>
> >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.
>
> Removable media (and network connections to untrusted systems) had
> slipped my memory.

Simone and I have just begun a discussion about how to transfer data  
between RSBAC systems without loosing security metadata. We hope to find a  
solution during summer. Asymmetric excryption will be a necessary part of  
this. The same scheme should work for all exported and imported data.

> >> 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.
>
> OK for processes IDs; maybe not for inode numbers.

We could completely hide inode numbers from user space - which program  
(apart from nfsd, which can be replaced by kernel nfsd) needs them at all?

> >> >                          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.
>
> To meet the assurance requirements, programs privileged to be able to
> change the process MAC label are required to be trusted not to exploit
> this privilege to break the MAC policy. In the case of /tmp (with
> partitioned directories) this means that they have to be careful about
> the MAC label associated with any data that they write to a file in
> /tmp.

We must be careful to distinguish between maximum (user) and current  
security level. In RSBAC all processes can change their current seclevel  
within bounds defined by maximum (=owner) level, minimum_write_level and  
maximum_read_level. Those not doing that themselves are moved  
automatically to maximize legal access.

This current level changing is the base of my problem. Of course I can  
leave the programs with the problem, but too many programs are standard  
Unix programs, which are not aware of it and thus might break.

BTW, I do not allow any trusted process to rise higher than its owner's  
seclevel. All processes marked as mac_trusted are only freed of the
*-property. Did I misunderstand Bell-La Padula in that point?

Amon.

--
Please remove second ao for E-Mail reply - no spam please!
## CrossPoint v3.11 ##
-
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.