Unix User Theory

[benthehutt]

Correct me if I'm wrong, but under *nix there is a root user and then the specific users.

                           Root User
                                |
                                |
                          Other Users

This means that if some user starts flippin' out he can't mess with stuff in the root user's domain, ie. critical system files, passwords, etc.  This also means that if a user (other that root) starts using a program and it flips out, it can only damage data of the user that started it.  My theory is to create an even lower tier on the hierarchy for specific applications, thus an application is only free to mess up its own files.

I realize that certain things it would need to access would be on other tiers, but could something be done like sudo from a users standpoint to tell what specific actions an application is allowed to carry out on a higher tier's files?

Any thoughts, basic ideas I'm overlooking, etc...?

[Metgod]

Could you elaborate a bit more ?

What are you trying to do ?

Do you mean you'd make a program that can be configured to only allow certain users to do certain actions related to that program, or something similar ? Or am I totally missing the point ?

If that's the case, you could always check the user id/effective id etc and just have a config file of sorts ...

If not then I don't understand what you're saying (in which case please tell us more).

[benthehutt]

Sorry, I wasn't too sure what I meant either.  I'm not trying to write a program, this is all theory.  Anyway, to start off, this is the basic user hierarchy:

Root
  |
Generic User

That being said, a generic user only has a certain realm of influence on his computer.  He cannot, for instance, mess with alot of the stuff in /etc.  That's because he would need root privileges to edit stuff there.  However, if a generic user starts up a program/service and that program/service gets hacked or goes haywire, it can screw up anything that that user that started it could screw up (mostly).  For instance, if an app on my box went off the deep end, it could delete all my school work, but it couldn't delete anything needing root privileges.

Now, my question is why not make another layer that goes like this:

Root
  |
User
  |
Application

Thusly, the application, (if it goes haywire) could only screw up itself.  It would not have the privileges to destroy the user's files that started it (or anything needing the root pass).

Is there something that stops developers from doing this?  I'm not sure I quite understand privileges...

[Metgod]

I atm can only think of three ways the program might 'mess up' like this:

- stack smashing/etc and shell code being used to execute arbitrary instructions by an attacker
- the program is trojanized
- the program actually was designed to do these things, so it's not really a problem (like 'rm' for example).

So, no, I don't think there is anything that prevents developers from doing this. But maybe I'm not understanding it completely ? (I'm guessing that's the case but I'll say a bit more anyway).


I can't think of any instance where a program would read/write files (thus having possibility to corrupt them) it does not actually need.

I suppose you could just have all paths relative to the program's data directory, but I don't see why or how what you're saying is a problem.

Could you provide an example ? I know in my projects I use the 'chdir' call to change to a data directory, and anything is relative to that directory I change to... thus if I open a file 'test' it'll be under that data directory (unless I specify something else like a full path).

If you do provide an example, I think it'd be easier to understand what you're saying ... but in general, a program shouldn't be touching files or configurations it doesn't use (there is no need to) by normal operation.

Looking at your post again, I see you mean if it messes up or is cracked. In the case of code being injected in to it, I can only think of a few things that would help prevent that.

Such things as PIE/SSP and PaX.

http://www.grsecurity.net/
http://www.nsa.gov/selinux/
http://pax.grsecurity.net/

Basically, kernels and compilers/etc can be patched to prevent these kinds of attacks (as in stack smashing). I don't use these on my servers because they making my things rather difficult to develop (debugging comes to mind as a bother with these things implemented).

But see also:

http://www.gentoo.org/proj/en/hardened/primer.xml

for some ideas on those things I mentioned (PaX, PIE, SSP etc).

If you still have questions, let me know and I'll get back to you soon (either later tonight or tomorrow - Wednesday).

[benthehutt]

I was talking mostly about hacking, yes.  So, basically any example of hacking a service will do.  I suppose you completely answered my question though.  I was looking more for "is this a good idea" or "this is implemented to kind of emulate that."  So thanks for the links!

[Metgod]

Glad to be of help!  

[Link3]

Why not use something like chroot'ed environment for protection ?

[Metgod]

that's in one of the links I posted even...

(chroot or in bsd jail)