3 ms·

"The old (other, group, user) * (read, write, execute) unix model is [...] sufficient for the vast majority of uses." It's really not, in an even moderately-co

"The old (other, group, user) * (read, write, execute) unix model is [...] sufficient for the vast majority of uses." It's really not, in an even moderately-complex environment. What I've seen most often is that the "user" and "group" permissions get eaten up by other factors (e.g. the "user" is a service account), so the only permission that can meaningfully be altered is "other". The result is that either all of the people who support whatever the app is doing have to be given sudo permissions as the service account (drastically reducing the value of any audit/logging), or access has to be controlled at the OS level in terms of who can log onto the system in the first place. In other words, band-aids to work around the limitations of the traditional Unix filesystem permission model.

beagle3 11y ago
Could you describe what the "group" gets eaten by? In most cases I've seen, the group works well as a permission set - e.g. "dialout" is for all users allowed to use the dialer, "lp" for all those allowed to use the printer, "audio" for those allowed to use the speaker, etc. Indeed, some pieces of software insist that the service user actually do everything, which is still supported with this model if the binaries are setuid with +x on owner and group but not other -- although, as you pointed out, auditing tends to suffer in this case. Speaking of which -- what's your favorite auditing setup? I need to set one up soon, I've been using auditd but it feels cumbersome.
- blincoln 11y ago
  Filter this response based on my being a pen tester, not a Unix/Linux admin - I'm much better at finding vulnerabilities and shortcomings than I am at coming up with a really good solution to them :). That's also why I can't give you a worthwhile answer about an auditing setup - I could tell you which ones I'm not super fond of, but I've never run the auditing side of things on Unix/Linux systems. The challenge I've run into with the group permission is that because there's only the owning group for the file/directory, there are basically two options: 1 - Leave the content owned by the primary group of the service account which also owns the file, and make support staff members of that group. This has the side effect of giving those support personnel access to just about everything else that group can get to, even if they don't need it. 2 - Create a new group that's just for delegating permissions for whatever content needs to be secured, and add both the service account and the users. This is analogous to using the new group as a quasi-ACL, IMO. It works, but quickly leads to group sprawl, and most of the Unix/Linux admins I've worked with are loathe to do it for this reason. A secondary challenge with #2 is that larger organizations will usually have group membership controlled by some sort of administrative team. So getting the group membership changed is a much bigger headache than the filesystem object owner modifying the ACL on their own content.

beagle3 11y ago

Could you describe what the "group" gets eaten by? In most cases I've seen, the group works well as a permission set - e.g. "dialout" is for all users allowed to use the dialer, "lp" for all those allowed to use the printer, "audio" for those allowed to use the speaker, etc. Indeed, some pieces of software insist that the service user actually do everything, which is still supported with this model if the binaries are setuid with +x on owner and group but not other -- although, as you pointed out, auditing tends to suffer in this case. Speaking of which -- what's your favorite auditing setup? I need to set one up soon, I've been using auditd but it feels cumbersome.

blincoln 11y ago
Filter this response based on my being a pen tester, not a Unix/Linux admin - I'm much better at finding vulnerabilities and shortcomings than I am at coming up with a really good solution to them :). That's also why I can't give you a worthwhile answer about an auditing setup - I could tell you which ones I'm not super fond of, but I've never run the auditing side of things on Unix/Linux systems. The challenge I've run into with the group permission is that because there's only the owning group for the file/directory, there are basically two options: 1 - Leave the content owned by the primary group of the service account which also owns the file, and make support staff members of that group. This has the side effect of giving those support personnel access to just about everything else that group can get to, even if they don't need it. 2 - Create a new group that's just for delegating permissions for whatever content needs to be secured, and add both the service account and the users. This is analogous to using the new group as a quasi-ACL, IMO. It works, but quickly leads to group sprawl, and most of the Unix/Linux admins I've worked with are loathe to do it for this reason. A secondary challenge with #2 is that larger organizations will usually have group membership controlled by some sort of administrative team. So getting the group membership changed is a much bigger headache than the filesystem object owner modifying the ACL on their own content.