Re: MAC

From: Stewart Robert Hinsley <stewart@meden.demon.co.uk>
Subject: Re: MAC
Date: Thu, 22 Apr 1999 22:42:29 +0100
Next Article (by Date): Re: MAC ao@morpork.shnet.org (A. Ott)
Previous Article (by Date): Re: MAC ao@morpork.shnet.org (A. Ott)
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 article <7FMeQnS$4iB@ao.morpork.shnet.org>, "A. Ott"
<ao@morpork.shnet.org> writes

<deletia; I may respond on the subject of inter-system transfers later>
>
>> >> 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?

Off the top of my head: ls(1) has an option to o/p the inode number.
This can be used by fuser(1) to identify a process which has its hands
on a file. find(1) also has an option to find a file with a particular
inode number. This can be used to map a kernel or fsck(1M) error message
relating to an inode to a file name. I've also used inode numbers in
cracking kernel dumps and dieing systems (on BSD and SVR4). clri(1M)
also used inode number as a parameter - but I think this has been
removed from recent systems. Inode numbers are useful to the end-user or
adminstrator in identifying whether two filenames (links) represent the
same file; but you could abolish links and require symbolic links (which
have their own security issues, e.g. in the area of Clark-Wilson), or
provide a kernel interface to test for the identity of two files. The
latter's not very user-friendly. 
>
>> >> >                          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.

IIRC, that's different from the MAC systems I've seen. MAC
confidentiality requires that data cannot flow from one container to
another container which does not dominate the first. Containers include
process address spaces. It is acceptable for a process's MAC label to be
raised; but it cannot be lowered again, unless it can be guaranteed that
no data has been added to the address space in the interim. (Even data
generated by the program counts; an analysis of raw data may be
classified as more sensitive that the raw data.)

Increasing a process's MAC label runs the risk of exacerbating security
creep - data been classified with unnecessarily high security levels -
unless the rules are designed to avoid this.

I do however agree with you that if a process's MAC label can silently
change underneath it the partitioned directory solution to shared public
directories is problematical. (It might be saveable, but I'd want to
think about it.)

The systems I've seen only changed a process's MAC label when it asked
for it to be done. As in these implementations the user's maximum level
resided in a file, not loaded into the kernel, the kernel was not able
to check the requested level against this, and therefore any change
required privilege. I designed an extended su(1), which would change
uid, gid, MAC label, privilege set, and other properties, at the user's
request, subject to contraints encoded in /etc/passwd writ large.
>
>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?

It's so many years since I read Bell & La Padula that my memory of what
they said is not to be relied on. (Is there a copy available online?)
However I've spent enough time documenting, reviewing, debugging, and
even writing, MAC systems, that I've internalised a few of the issues.

As I said above a pure MAC confidentiality mechanism is intended to
prevent the flow of information from a more secure to a less secure
container, or between compartments. However there are practical problems
with such a pure system, assuming a pure kernel implementation. Consider
backups. An operator quite probably has a low clearance. However a
system backup has the highest security level. A backup program has to be
able to read any file in the system. Thus it has to either be able to
raise its level above the operator's, or be freed from the constraints
of the MAC policy. The backup program must be part of the trusted
computing base (TCB). Similarly a restore program extracts data from a
high level backup, and may write it to a lower level file. It is also
part of the TCB.

A case can be made that the process MAC label must rise to the maximum,
to prevent access to data in the process's address space via the
equivalent of /proc. (An alternative implementation can be based on the
comparative privilege sets of the two processes involved; except that it
applies to all privileges the backup/restore processes ever had, not
their current sets.)

A summary of my position is that TCB processes enforce the Bell-La
Padula model (or whatever variant is specified by the system's security
policy), but need not be constrained by the corresponding kernel
mechanisms. Whether they are or not is a design and quality of
implementation issue. It is wise to constrain such processes as far as
is consistent with a clean implementation, for assurance reasons.
>
>Amon.

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