Re: Securelevel bitmap patch

Alexander Kjeldaas (astor@guardian.no)
Mon, 30 Mar 1998 17:30:08 +0200


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.

astor

-- 
 Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
 http://www.guardian.no/

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