> On Wed, 2002-10-30 at 21:31, Linus Torvalds wrote:
> > > 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?
> >
>
> 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
On Thursday 31 October 2002 04:59 am, Trever L. Adams wrote:
> 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.
>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.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Thu, 2002-10-31 at 11:47, Jesse Pollard wrote:
> On Thursday 31 October 2002 04:59 am, Trever L. Adams wrote:
> > 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.
> >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?
> 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.
> 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?
> 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.
On Thursday 31 October 2002 02:28 pm, Trever L. Adams wrote:
> On Thu, 2002-10-31 at 11:47, Jesse Pollard wrote:
> > >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?
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.
...
> > 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).
> > 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.
> 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.
> 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 :-)
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.