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

From: janos.milus@dataware.debis.hu
Subject: Re: A little patch - init security level and MAC categories and a
Date: Thu, 18 Jan 2001 14:39:52 +0100

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

- You are right, MAC is just one model (but maybe the most important
becouse of NSA standards)

- The mknod trick works, thank you. I think using the 0:0 device as
"default" to others not good idea. I must think it off, but you may want
separate the devices: one person has rights to config the network cards,
other has rights to mount proc etc. The best solution to this problem that
you can assign rights to this devices "symbolic" names, but it not really
nessessary:  while you don't change the boot sequence, the proc and the
other device-less devices have always the same minor number. (But it makes
your life easier if you can use symbolic names).

- As it works and have enough time I will document how my sandbox works and
how can you build one. I plan to finish with the draft version at the end
of the next week. Where should I post it? To you or to the list? (And who
will check my grammar? I think it is awfull ;) )

Regards
Janos Milus




Amon Ott <ao@rsbac.org> on 2001.01.18 09:56:12

Please respond to RSBAC List <rsbac@rsbac.org>

To:   RSBAC List <rsbac@compuniverse.de>
cc:

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




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.






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