Re: MAC

From: Stewart Robert Hinsley <stewart@meden.demon.co.uk>
Subject: Re: MAC
Date: Wed, 21 Apr 1999 18:43:56 +0100

Next Article (by Author): Re: MAC Stewart Robert Hinsley
Previous Article (by Author): Speed of rsbac ? Sebastian Andersson
Top of Thread: Re: MAC ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: MAC ao@morpork.shnet.org (A. Ott)
Articles sorted by: [Date] [Author] [Subject]

In message <7EzQKBi$4iB@ao.morpork.shnet.org>, "A. Ott"
<ao@morpork.shnet.org> writes

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

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

-- 
Stewart Robert Hinsley
-
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.