Messages in this thread | | | Date | Mon, 30 Mar 1998 22:39:45 +0200 | From | Andrej Presern <> | Subject | Re: Securelevel bitmap patch |
| |
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
| |