OSDev.org

In my operating system I will have a unified namespace by which everything - files, drivers, address spaces, processes and resources - can be accessed. This will be organised in a tree structure, and named the object tree. Of course, for this a good and extensible security system will be needed. I need help in deciding what kind of security system to use that will define who can access each of the objects.

Let me first describe some more of how the system works so you can get the bigger picture:

Some things like filesystem security will actually be handled by their respective drivers, since the objects they handle will only 'appear' to be part of the main object tree. This is done using 'containers' containers link one part of the object tree to another tree, so as any request interpretter travels down searching for an object, if it sees a container, it will then forward the request onto that tree's handler (i.e the filesystem driver). Thus the security proceedures need only be applicable to objects in the main tree.

Objects in the main tree can be of different types (which will later be creatable dynamically at run-time). Each object must have the same header which contains: its name, type, brother and son. The last two values are the one that link the objects together, as shown below (- denotees brotherly connection, | denotes a son)

Root
|
Devices ----------- Processes
| |
Networking - Storage - Visual 1-2-3-4

Thus, we end up with a tree structure.


--------------------
For this large structure I will need a good security system that is simple yet efficient and flexible enough to meet most concievable need. Any ideas (i.e ACL's, etc)?

Thanks in advance for any suggestions,
OScoder

I never quite got why everyone goes this way these days, taking the method used in *nix systems and running as far as possible with it. As far as I'm concerned (and indeed my OS would be if I had enough time to dev currently), processes are very different things to files, which are again very different to devices. I can imagine very few scenarios where a common access mechanism is useful as anything other than a gimmick.

That said, this is your choice and I'll provide you with any pointers I can think of. In terms of accessing things on the tree, all it would require is a standard function (or set thereof) which can be used to enumerate/status the item (a pointer to which could be provided to the kernel when a device driver or filesystem driver registers itself, etc).

Security-wise I'm not quite sure. It would have to be rather extensible if you allow new types of things to be added to the tree dynamically, so something like an ACL could be appropriate in this case, if slightly slower than methods such as a simple rights bitmap.

Your design is pretty much the same as mine. My objects have a unix-like rights bitmap by default, which can be overridden by a fully fledged ACL if need be. Access rights are given on a per-process basis.

Cheers,
The Senaus

hmm, the problem with rights-bitmaps and ACLs for me is that they are both based on users or groups. The idea behind the object tree was to make it fully intergratable with other trees (i.e for a distributed system). This would then require a centralised user management system.

One idea I though of was based on capabilites. Each object would have a list of keys (MD5 Hashes), which would give the calling process certain rights if presented. Of course, this then creates the problem of key distribution, and also of checking whether a calling process on the network has the solution to a certain key.

One of the biggest problems is if a fraudulent computer on a network asked for the solution to a key it did not have, and the user gave the key thinking it was a legitamate, request, then the fraudulent computer could get all that user's keys (if you see what I mean).

Is there a way for someone to prove that they have the solution to a key, without giving away the answer?

You want a challenge-response system.

The server shares a key 'K' with the client (server has 1 key per client). K could be a hash of a users password (for user authentication, the user would provide the server with his password) or a key assigned to the client computer (for computer authentication, the key would be typed into server and client during setup). The server randomly generates a value 'x' and calculates:

Q = f(K, x)

The server stores Q and sends x to the client, which does:

R = f(K, x)

Now R is sent to the server. If Q and R match, the server knows the client has the correct key without the key being exchanged.

This is a hugely simplified version of things and in practice the function f() has to be very carefully chosen (I'd use SHA-1 for a simple setup). You need to read up on cryptography if you don't understand this (I understand it but could hardly put together a real crypto system, I know only the very basics).

If I'm wrong, beatings with a clue-by-four would be welcomed,
Paul Barker

Sorry, missed two things:

The whole point of this is that an imposter could grab x and R, but when the imposter is challenged he will get a different value of x so his value of R is invalid. The generator for x must avoid duplicating previous values (MD5 or SHA-1 random number generator is a good choice).

Also, for f() - the function must be one-way (MD5 or SHA-1 again being good choices). It is never necessary to go backwards so a hash function is used rather than an encrypt/decrypt function.