Re: A little patch - init security level and MAC categories and a question

From: Amon Ott <ao@rsbac.org>
Subject: Re: A little patch - init security level and MAC categories and a question
Date: Thu, 18 Jan 2001 09:56:12 +0100

Next Article (by Date): Re: A little patch - init security level and MAC categories and a janos.milus@dataware.debis.hu
Previous Article (by Date): Re: A little patch - init security level and MAC categories and a janos.milus@dataware.debis.hu
Top of Thread: Re: A little patch - init security level and MAC categories and a question Amon Ott
Next in Thread: Re: A little patch - init security level and MAC categories and a question Amon Ott
Articles sorted by: [Date] [Author] [Subject]

On Mit, 17 Jan 2001 janos.milus@dataware.debis.hu wrote:
> - IMHO theorethically the init is as common process as the shell or any
> other process in the system. The RSBAC should manage this process the same
> way as the others. As I known in the Bell-La Paula model when a process
> starting it got its owner's rights.  So, when the init gets security level
> and MAC categories it should get it's owner, the root security level and
> categories. Not more nor less.

Already implemented. I also thought about an additional special user value for
init with separate attributes, but a soon as init executes something, that
program gets root's privs anyway.

BTW: MAC is only one model, and the RSBAC is supposed to be as model
independent as possible.

> - I think the solve of the problem of the device-less mount is not so
> simple. You can use RSBAC (and MAC) to build a very good jail: for example
> every file and directory in the system has 11000...0 MAC category, but
> there is a /sandbox directory which has 10000...0 category (and every file
> and directory under /sandbox has 10000...0 category of course). You can
> build a complet linux system under /sandbox and you can chroot to /sandbox.
> After it processess running in /sandbox can't break out. But if you can
> mount proc (becouse there is no attribute check) you can access some very
> dangerous thing, for example the kcore.

You have a good point here. I just reversed the check removal. :)

What you can already do now is e.g.
mknod /dev/dev0.1 b 0 1
and then use the usual tools to set attributes via /dev/dev0.1 etc. If you
repeat this for minor numbers 2 to 254, everything is fine... ;)

The problem is that we still deal with dynamically assigned minor numbers.

As far as I know, dev 0:0 is reserved as null value. We could use this special
number for default values for all 0:xxx devices. How about that idea?

Notes:
- ACL already has the DEV default ACL, which can be used to solve the problem
- In RC, you can allow mounting only for a special role, e.g. 'Mounting', and
set rc_force_role for /sbin/mount and /sbin/umount to this role. Only people
who can run these binaries are then able to (u)mount anything. Or use an extra
RC DEV type, ......
- kcore and some other proc files are already protected via SCD
targets. In MAC model, access rights to them are hardcoded via system role, in
other models, e.g. RC or ACL, you can define your own access rights.
- Would you mind writing down your sandbox example for beginners? I'd like to
start a new Examples section on the Web server with user contributed examples.

Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.