Re: Securelevel bitmap patch

Andrej Presern (andrejp@luz.fe.uni-lj.si)
Mon, 30 Mar 1998 22:39:45 +0200

Alexander Kjeldaas wrote:
>
> On Mon, Mar 30, 1998 at 10:26:21AM +0200, Andrej Presern wrote:
> >
> > By using bitmaps you are restricting yourself to at most a specific
> > number of capabilities and you don't get very fine grained security
> > anyway (instead of black and white you get shades of gray). You want a
> > process to have the least authority that is needed to get the job done
> > and you can't get that by having such a coarse grained security.
> >
> > The right approach would be to make each object <-> action relationship
> > a capability that can be given to any entity in the system (ie you want
> > a true capability model). An example: you want a process to be able to
> > modify /etc/passwd. So you simply create a modify_etc_passwd capability
> > and delegate it to processes that you want to be able to modify the user
> > database. If you want some processes to be only able to read (but not
> > modify) the database, you create another capability, the read_etc_passwd
> > capability, if you want the process to be able to modify the kernel, you
> > give it the modify_kernel capability, and so on.
> >
> > Notice that in a true capability model /etc/passwd is just another
> > object, same as (for example) your ~/.profile, so you could as well let
> > the _users_ create their own execute_~_.profile capability and delegate
> > it to other users (and even their own processes, selectively that is).
> > Carefull observers have probably already noticed that this model is
> > clearly superior to any form of ACLs since having a capability is
> > sufficient for the process to be granted the desired access. Besides
> > being very flexible, this model also simplifies and speeds up a lot of
> > things, and - considerably improves security.
> >
>
> How do you implement this? To me, it seems that the hardware these
> OSes run on often is a bit unconventional, like the PowerPC AS
> processors used in S/390 and AS/400. They support tagging, special
> bits hidden from user-level programs. On conventional hardware, you
> have to implement general capabilities by storing them in kernel
> memory [with a 64-bit mmu you might try a "password" approach - you
> know the address, you have the capability]. But then you (might?) get
> a performance problem so you won't use it for fine-grained access
> anyway. If or when general capabilities are implemented, they
> superceed the capabilities implementation done in linux-privs and
> should be able to support the interface in a backward-compatible
> manner.

Fortunatelly, this is also very implementable (and actually already is
implemented) in IA32. The performance has actually gone up, whereas the
size of the kernels have gone down compared to normal ACL model based
implementation. This is not surprising since a lot of superfluous 'if'
(and similar decision-making) statements is eliminated - the check needs
to be done only once (whether the process contains the capability or
not) and is doable in only a few assembler instructions.

The control is very fine grained. Compared to perimeter (1) and ACL
based models (2), where 1:the objects in the system trust each other but
are all together protected from the outter world by some sort of a
firewall that selectively filters input and output, and 2: access to the
'holes' in the firewall through which the data is flowing is delegated
to the objects according to (usually several, which impacts performance)
access lists and _all_ of the possible (intentional or unintentional)
entry holes must be covered by an access list (otherwise you have a
security hole), the capabilities model doesn't try to stop the bad guys
by checking if they are _not_ allowed access but rather lets in those
who _prove_ they are allowed. The process proves that by having a
'capability' for the object _and_ the action it is going to perform on
the object. This capability can be thought of as an entry ticket, or
better, a key, where only a matching key will open the padlock. I can
have a key (to my house for example) but this key has only one lock that
it will open (ie it won't open your house). By having this key the lock
lets me in - it is a sufficient authorization as far as the lock is
concerned. If this particular lock gives me too much authorization (for
example, a password to the root account), it can be replaced by more
finely grained lock (ie, if it's not good to have a lock on the front
door since there will be strangers (untrusted persons) entering the
house (for example, if I'm running an office of some kind), I can remove
it from the front door and use locks on the furniture and private rooms
that the visitors are not supposed to enter.

I hope this all sounds connected because it's not easy to explain an
alternative approach to people who have all their lives thought in the
terms of access lists (the vast majority - basically all mainstream
operating systems, including UNIX and NT, are ACL based).

As far as backward compatibility is concerned, all of the existing
interfaces can be preserved (ie 100% binary/source backward
compatibility) but I believe it is only a natural thing that with time
more security aware applications will be built to exploit the potential
that capabilities offer and that will replace the old ones.

Andrej

-- 
Andrej Presern, andrejp@luz.fe.uni-lj.si






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu