The ACL debate (was: Re: What's left over.)
Quoted 7 lines · Linus Torvalds
Quoted 5 lines
Quoted 1 line
ext2/ext3 ACLs and Extended Attributes
I don't know why people still want ACL's. There were noises about them for samba, but I'v not heard anything since. Are vendors using this?
Quoted 9 lines
I am sure I don't count (not being a vendor), but Intermezzo offers support for this (they are waiting on feature freeze to redo it to 2.5 according to an email I have). I want this stuff. Yes, u+g+w is nice, but good ACLs are even better. Please, if this is technically correct in implementation, do put it in.
Thank you,
Trever
I know, bad form and all following up to myself. Everyone keeps mentioning how bad ACLs are and how they need user-space regulation. Let me explain what I see, what I believe Windows NT/XP does, and hopefully we can reach some consensus among those who really know.
Problems with normal Unix permissions:
1) You only have three categories (user/owner, group, world/other).
2) Owner can't offer (transfer) ownership to someone else (NT does this right by making it belong to the owner until the potential new owner accepts).
3) Limited number of groups.
4) Only root can add groups
5) Only root can change group ownership of a file
What I see NT doing:
1) Owner can allow read, write, delete, execute to anyone or any group (this is great, though delete and write might as well be the same thing I think)
2) NT Kernel + fs dictates rights, not the user-land
3) Non-owner user cannot give rights to anyone else (though, I believe they can remove rights from themselves, though it has been a LONG time and I am not sure)
4) Owner can offer transfer of ownership (though this may be dumb in Linux)
5) No need for groups for small numbers of additional users with rwx abilities
6) On copy the ACL is reset to the owner only.
7) On move, it copies the ACL (see problems with ACLs below)
Where does user-land fit in:
Right now it fits in with chown. I believe everything else is done in kernel for permissions now. Why are we blaming everything on user-land now with more powerful ACLs/permissions? You need a tool that can request that the kernel do xyz update on the ACL for file abc. The kernel then says done, you are the owner of the file, or heck no, go away you aren't the owner even if you have rwx privileges.
Why ACLs are needed:
I know many people who would love to move to Linux for all sorts of things, but they need ACLs. Sysadmins can't always be running around chowning things for different groups, adding users to groups, removing users to groups, removing dead groups, etc. ACLs allows the owner of the file to do things as they really should be done. ACLs do need at least a concept of additional users (not owners) of a file. It would be nice if it would work with groups too, even if root intervention was still required for creating groups.
Why are ACLs bad:
1) It takes some brains so that you totally don't screw yourself over with your data... however this still can happen with the current Unix permissions. It just becomes more complex.
2) More complex kernel code... well every feature does. I believe this one is worth it.
3) Different file systems have different ACL sets... OK, so what. User-space just needs to be able to know what they are on each fs, as does the kernel. I don't really think there needs to be a huge issue, other than on a move. Copy would reset the ACL to the owner's default (the new owner, not the original file owner). Move needs to be able to copy the ACLs with the file. Within the same fs type (even if different volumes), this should be easy. Between fs types, this may be a problem.
4) New/update user space tools required. All new features do. Heck, networking needs new versions all the time.
5) Disk/kernel bloat. Make it a compile time option I guess. Those who need/want can have, those who don't, good too.
Does POSIX ACLs do all this:
I have no clue. I don't know if they are sane or not. I see a proper ACL definition just extending and working with standard permissions including the rules of inheritance and priority.
Am I crazy:
I may very well be. I may have no clue what I am talking about. However, I wrote this because I really don't see all the arguments about how horrible it is because of user-land.
Can most of the positives be emulated via setuid apps:
Maybe. However, you still are limited to three fields of authorization, verses the many more of the other. Also, it would require more user-land updates to do this than to do it with ACLs IMHO.
Thank you for your time and corrections where I am wrong. Please, direct flames to your /dev/null mine is full :)
Trever Adams
Quoted 1 line · Trever L. Adams
5) Only root can change group ownership of a file
not quite - the owner of the file may change the group ownership to any other group that the owner is a member.
It does require root to change a file group to a group the owner is not a member of.
Quoted 1 line
Why ACLs are bad:
ACLs alone are not enough. ACLs alone allow a user to grant access to any other user/group. For situations that require a fence between users (ie. accounting/parts inventory) only a mandatory access control (MAC) would be able to prevent such improper data sharing. It is also a problem in government use. At least on large, shared resource systems.
Putting users in disjoint group memberships accomplishes this. Providing ACLs can allow improper sharing since that is a descretionary permission.
Mitigating factors:
Adding MAC restores facility control, and still allows the user some flexibility to create ad-hoc groups within an administratively defined population group.
The normal UNIX solution is to have multiple systems, each dedicated to a relatively small population where any user is authorized to access data on that system (this is where limited groups come in), but owners of the data may provide a more restricted access.
Having dedicated resources corresponds to the MAC access control. Having owner/group/world access controls (and/or ACLs) provides the owner with a descretionary access control for the administratively controled population of users.
A large resource usually has to be shared (wind tunnel simulations, finite element analysis of different structures, large inventory management...). And sharing doesn't necessarily involve sharing data.
Signature · 5 lines
------------------------------------------------------------------------- Jesse I Pollard, II Email: [email protected] Any opinions expressed are solely my own.
Quoted 9 lines · Jesse Pollard
Quoted 1 line · Trever L. Adams
5) Only root can change group ownership of a file
not quite - the owner of the file may change the group ownership to any other group that the owner is a member.
It does require root to change a file group to a group the owner is not a member of.
I guess my experience with playing with groups is lacking. I had tried this, but I guess I always tried with groups I wasn't a member of. I still believe this is bad form, but probably has historical and valid reasons for it.
Quoted 9 lines
Quoted 1 line
Why ACLs are bad:
ACLs alone are not enough. ACLs alone allow a user to grant access to any other user/group. For situations that require a fence between users (ie. accounting/parts inventory) only a mandatory access control (MAC) would be able to prevent such improper data sharing. It is also a problem in government use. At least on large, shared resource systems.
I see your point here too. I usually see things from a perspective of
companies not needing this. I mean "a house divided..." and all that.
But I guess companies would rather force unity than let the one person screw them over. Point to you on the debate for sure. I know there have been MAC implementations for Linux... is one in 2.5?
Quoted 6 lines
Mitigating factors:
Adding MAC restores facility control, and still allows the user some flexibility to create ad-hoc groups within an administratively defined population group.
Sounds very good. I would think for those who know they are united, that MAC or ACL should not auto-define the other. Having both, on option, is nice though.
Quoted 5 lines
The normal UNIX solution is to have multiple systems, each dedicated to a relatively small population where any user is authorized to access data on that system (this is where limited groups come in), but owners of the data may provide a more restricted access.
Hardware is getting more powerful, why segment it through such physical means?
Quoted 4 lines
A large resource usually has to be shared (wind tunnel simulations, finite element analysis of different structures, large inventory management...). And sharing doesn't necessarily involve sharing data.
Understood. You had many good points. I still don't see it as a user space problem though. These are all things that go in the kernel... Yes, policy doesn't belong in the kernel, but the ability to create policy and enforce it does (where user-space may not be the right place, such as here).
I guess I agree with you, but I still think ACLs are necessary and wanted, even if there needs to be additional functionality for those who are totally paranoid (some corps, governments, etc.)
Trever Adams
P.S. I removed Linus from direct in the email because he has said he is going to add it already.
Quoted 11 lines · Trever L. Adams
Quoted 8 lines · Jesse Pollard
Quoted 1 line
Why ACLs are bad:
ACLs alone are not enough. ACLs alone allow a user to grant access to any other user/group. For situations that require a fence between users (ie. accounting/parts inventory) only a mandatory access control (MAC) would be able to prevent such improper data sharing. It is also a problem in government use. At least on large, shared resource systems.
Quoted 5 lines
I see your point here too. I usually see things from a perspective of
companies not needing this. I mean "a house divided..." and all that.
But I guess companies would rather force unity than let the one person screw them over. Point to you on the debate for sure. I know there have been MAC implementations for Linux... is one in 2.5?
It is planned - The SELinux module is working under the LSM additions and does define MAC controls. Policy is defined in an external file and compiled and supplied to a kernel module for interpretation/enforcement.
...
Quoted 7 lines
Quoted 4 lines
The normal UNIX solution is to have multiple systems, each dedicated to a relatively small population where any user is authorized to access data on that system (this is where limited groups come in), but owners of the data may provide a more restricted access.
Hardware is getting more powerful, why segment it through such physical means?
It was just a historical note of how MAC was implementd, and still is for the government. It is not currently allowed to mix data of differing security levels or compartments on one system (even on large and very EXPENSIVE ones).
Quoted 10 lines
Quoted 4 lines
A large resource usually has to be shared (wind tunnel simulations, finite element analysis of different structures, large inventory management...). And sharing doesn't necessarily involve sharing data.
Understood. You had many good points. I still don't see it as a user space problem though. These are all things that go in the kernel... Yes, policy doesn't belong in the kernel, but the ability to create policy and enforce it does (where user-space may not be the right place, such as here).
Most of the problem isn't. I do believe ACLs should be present for discretionary controls. Without MAC controls though, you do end up with possible global/unregulated access without a real visible clue. AND no way to restrict it.
We have an 8 million inode file system, and if we search the entire thing, even for world read trees, would take hours to scan.
Quoted 3 lines
I guess I agree with you, but I still think ACLs are necessary and wanted, even if there needs to be additional functionality for those who are totally paranoid (some corps, governments, etc.)
I do think they need to be there. There are some significant uses for it:
1. restricting access to devices (a users should not be able to access audio/tape/floppy/CDwriter unless an ACL on the device permits it.)
2. access to special system owned applications
3. protecting system files (consider an ACL on the /etc/shadow file; vmlinux, all files in /bin /usr/bin)
4. delegating update capability (ACL on /usr/local allows an applications group to supply updates, instead of root).
Some/most of this is already done by changing group/owner access to the files.
The advantage of MAC labels over ACLs for the above are that if root IS compromised (or the an application group...), it will be next to impossible to modify these files because the penetration (by definition) is bypassing standard authentication rules. Since these rules are not satisfied, the label assigned to the process will not be granted.
Without that security lable to match against the files, the files will still be protected. Even from a root break in. Yes, some damage could occur. but the system should still be safe.
It doesn't protect against stupidity, or highjacking an already existing communication channel that has already been authorized. It does protect against hacking most service daemons, since these daemons should not be using an all powerful security label. That would be just as bad as running them as root is now.
And that appears to be the goal of most of the MAC implementations. Minimize the capability of processes to only what is needed to perform the job.
Quoted 4 lines
Trever Adams
P.S. I removed Linus from direct in the email because he has said he is going to add it already.
Just building a case for MAC later on :-)
Signature · 5 lines
------------------------------------------------------------------------- Jesse I Pollard, II Email: [email protected] Any opinions expressed are solely my own.