That wasn't always true. In the past, it was common to have having multiple untrusted users in one system. Outside of universities that is now uncommon.

It's much more typical to have one operator own (or a small team share) a large number of unix hosts. The common models here for dealing with privileges are more an exercise in getting aroung it than leveraging it.

One model is to have an app user that everyone logs in as. This reduces the change of people making a mistake when they're root, but it's hard to know who did what.

Another model has each person have a unique user. They log in as themselves and then sudo to application users. It's a fair bit of work to set up, and once you have you still don't get to see who ran what command.

In theory you can set things up so that everyone is in the same group, but there's fiddly problems when you do this. Like you can't copy over someone else's file (even if you're in the group and it's 775), you have to first delete it and then copy in its place.

A model I'd prefer would be to have a gateway OS housing multiple VMs. A vm would have full rwx access to a mount point on a filesystem. Any user within the vm would have full permissions. The system would log into the gateway system. If you had particular security needs, you'd implement them at an application level.

Privileges make the unix code and user experience significantly more complicated. I don't see a payoff that justifies the cost.

This sounds...sort of familiar...

(http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs)

Sadly; *nix was just good enough.

http://doc.cat-v.org/plan_9/4th_edition/papers/auth

I think we'll eventually move to that but it could take decades.

I actually agree with you - the Posix privilege model is dated. But it's still working fine, with additions like the MAC (SELinux), xattr's and ACLs, and now capabilities.

[1] http://www.slideshare.net/pragatiogal/understanding-android-... slide 5/30

However, with the arise of KVM (and other virtualization systems that no longer slow down your guest systems), I'm switching to KVM for those tasks.

Is this a personal anecdote or do you have actual evidence?

More importantly your discussion of users/privileges does not take into account separate users for separate processes within the system. Do you think postfix/mysql/apache/whatever-daemon should all run as the same user? Different daemons are essentially different untrusted users and I am glad that unix treats them this way.

Without separate users how do you do backups safely and reliably?

I am not positive but I think that a modern windows system has different users for different processes..

Or any of a million other ways:

  $ sudo /bin/bash
  $ sudo su
  $ cp /bin/bash ./; sudo chmod u+S ./bash; ./bash
  $ sudo less # invoke /bin/bash from inside less

Here's 2 ways I know of:

- Linux Audit. Just have auditd tracing all execves. All execs made after UID transision (sudo su, sudo -s, what not) have a AUID appended that is filled with the original "logged-in-as" UID.

- RSBAC. Does basically the same thing

Both are kernel side. Userspace tools to control.

And a nuclear reactor does basically the same thing as my electric tea kettle;)

If anyone knows of a good place to look for information to help me understand users and permissions, especially in regards to modern web applications, I'd love to hear about it.

What is it that you do not understand in regards to modern web applications?

(Jails are used because while httpd normally cannot overwrite those files, exploits crop up every now and again that allow privilege escalation; jails are an attempt to obviate that problem)

Why complicate the issue with jails? User separation is in the same vein as user permissions, thats true. But they are hardly on the same plane. If someone is interested in understanding the basic u/g/w+chmod permissions model why would you bring up jails? Now there is twice as much to explain because you have one system+users running inside/ontop of another system+users.

Anyway breaking out of a chroot jail is not terribly hard if you have elevated priveleges above www-data inside of the chroot.

Oh good, a friendly one.

Why complicate the issue with jails?

Jails are very easy to understand. Once you understand jails, it should be an easy logical step to understand users/groups on a conceptual/purpose level, as they can be viewed as very sophisticated jails.

I'm solving a similar issue, but prefer to put the "gateway" part into a separate VM as well. This is a very small VM, mostly consisting of forwarding and proxy services. That way, the main OS does nothing more than hosting the VMs, and it is less likely that the whole system breaks while making changes to the gateway system.

Authorization will always be hard because working out what each person should be able to access and then giving a meaningful way of describing that is hard.

Object capabilities would bring reasonable security to the OS, so we wouldn't have to use clumsy VM's as a security model. Unfortunately, the mistake of the 1960's (ACL-based security) stuck to this day, and object-capabilities were barely put to use.

http://en.wikipedia.org/wiki/Object-capability_model

For example RSBAC (www.rsbac.org) has a CAP module and which can forbid capabilities per process.

This won't save you when the kernel request it, but it doesnt when an app require it while it doesn't need it, which is what the article is about

That is, the developer does not need to bother. The developer does what the developer does.

The policy enforces it, regardless of the code. If in certain conditions, as a user, you disagree with the user of CAP_SYS_ADMIN, RSBAC denies it (context-based too, via other modules!)

You can for example wrap that in a role-based policy, tied per binary, or simply by wrapping it in a RSBAC jail. (rsbac_jail -options /path/to/said/program)

I don't think the other ones do that, as it's quite specific. They just plain deny.

That's mostly because RSBAC has it's own framework (as does GrSecurity, but GrSecurity does not go as deep in that regard)