Re: MAC

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: MAC
Date: 23 Apr 1999 19:28:00 +0200
Next Article (by Date): Re: Problems with 2.2.6 kernel ao@morpork.shnet.org (A. Ott)
Previous Article (by Date): Re: MAC Stewart Robert Hinsley
Top of Thread: Re: MAC ao@morpork.shnet.org (A. Ott)
Articles sorted by: [Date] [Author] [Subject]
********* ***************** ********** ****  *****   ***** ************
  To subject Re: MAC
  stewart@meden.demon.co.uk (Stewart Robert Hinsley)  wrote:
********** ******************** ******  ********  ******* *************

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

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

I fear we have to keep inode numbers visible then. Still, they are in most  
cases only another representation of what is usually accessed via names.  
The important thing here is that you cannot open a file by inode, or in  
any other way influence the inode number. Even guessing it is not easy to  
do.

> [..] >[/tmp dir problem]

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

Illegal information flow is fully prevented by my system, but it is more  
flexible. The automatic level changing mechanism and the boundaries are my  
own solution to the problem of standard Unix programs which cannot change  
levels by themselves - they do not know about them. Later I added the same  
for compartments, using set algebra.

The upper bound min_write just records the minimum/intersection of all  
levels/compartments of all objects (files etc.) a process has write-opened/ 
written to since the last execute. The lower bound max_read is used the  
opposite way. By keeping the current level/compartment set between them,  
ss- and *-property are always maintained.

Executing a program clears all process memory, so the bounds can be reset.  
Subprocesses inherit their parent's boundaries.

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

The default (start) value for current_level/current_comp_set can be set to  
minimum at compile time. If the process writes to an unclassified  
directory or file, it is kept at minimum anyway.

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

This headache made we change my focus to other problems... ;)

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

My approach of keeping as much security information as possible in kernel  
space made a few things easier.

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

In the current RSBAC implementation backups must be run with highest level  
and full compartment set. The same holds for the restore program, which  
additionally must be marked as mac_trusted to be allowed to violate *- 
property (write to lower levels).

The labels themselves have to be restored separately at the moment, what  
makes the restore a simple 'boot maintenance kernel, restore files,  
restore attributes as root and reboot normal RSBAC kernel'. This might be  
changed with the export solution mentioned before.

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

No, the data should be kept at minimum level. Proc access is special and  
should follow the same rules as before, treating processes as objects.  
This is already done for signalling. The proc protection is not yet  
finished in this regard - proc has been changing constantly during 2.1.xxx  
kernels.

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

RSBAC approach is that there are no TCB processes, just kernel code that  
is protected against all processes. In real life this is Linux and there  
are always TCB processes, e.g. /bin/login and /bin/passwd, but they are  
more and more protected by RSBAC mechanisms.

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.