Why are they going deeper with it? The more I deal with unix, the more I feel that permissions are a mistake.
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.
>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.
Some of the privilege "jails" on a unix system are for programs. Android jails each app by assigning it a unique user ID. [1]
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.
For a long time, I was using Linux-VServer (that's a "BSD jails" equivalent for Linux). It worked really well. But it allowed only for Linux guest systems, and the virtual networking often had some unexpected holes and flaws (maybe "BSD jails" work better in that regard).
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.
"In the past, it was common to have having multiple untrusted users in one system. Outside of universities that is now uncommon."
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..
For the binary "trusted or not" scenario can't you just have sudo-to-root? That tracks each user's actions (if they don't sudo -s) and gives the trusted/entrusted split. (bob can sudo but WWW-data can't).
- 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.
The bash shell, as of v4.1, can syslog every command, if you enable it at compile time. Very useful, we use it on all our prod boxes. Take all the other shells off the system and it becomes much harder for a hax0r not to leave an audit trail.
What I meant was that your group needs to have one "social" rule, "run all admin cmds under sudo, don't spawn a root shell and do it all there", for you to have effective tracking.
Posix 'capabilities' are a neutered version of actual capability security such as capsicum in FreeBSD. Linux is trying somewhat to go this way with seccomp2 and perf but Linux is Linux and things usually evolve by bolting on additions instead of fixing the core problem. I honestly don't see why Linux doesn't adopt capsicum instead of reinventing the same thing.. poorly.
Permissions have always been a mystery to me. Especially when you toss in things like an 'httpd' user or a 'postgres' user. I've only ever been able to find explanations about what permissions are, but never a description of how and why modern use of *nix permissions work.
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.
Separate users for separate daemons provides an informal "privilege separation." If apache starts misbehaving it will not be able to write to any of the files that belong to postfix.
What is it that you do not understand in regards to modern web applications?
It's not just apache misbehaving- it is in a similar vein to application jails. If someone hijacks the apache server, they cannot direct httpd to overwrite /etc/passwd or /etc/ssh/sshd_config.
(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)
What a great post. You just confused the issue more and added nothing. I was trying to see if I could help explain the user permission model to the OP. Overwriting files is misbehaving doing anything but answering http requests is misbehaving.
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.
Hi, almost every post you have made in this thread has a disrespectful tone. please review what you're doing, avoid "...", don't be sarcastic, don't assume the other person is an idiot.
What a great post. You just confused the issue more and added nothing.
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.
A model I'd prefer would be to have a gateway OS housing multiple VMs.
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.
Groups are quite useful in "need-to-know" information partitioning schemes. I personally haven't run into these fiddly problems you speak of, besides improperly set files (e.g. a 740 in a tree of 775).
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.