Rich access control lists
Rich access control lists
Posted Oct 22, 2015 18:55 UTC (Thu) by idra (guest, #36289)In reply to: Rich access control lists by nybble41
Parent article: Rich access control lists
> No, it's counter-intuitive because of how groups work in the real world. Being a member of a group is a privilege, not a burden. Being accepted into a group has positive connotations; rejection is negative.
This is not the reason why negative ACLs are bad, they are bad because they do not fail safe.
If an ACL is accidentally dropped in a Posix like system you lose access, with DENY ACLs if a DENY ACL is dropped then you gain access, which is a much worse failure mode.
Pure Windows semantics are even worse, and *are* counterintuitive, because not only they provide DENY ACLs, they are also *ordered*. And many admins do not understand the complex relationship that arises when you DENY *after* an ALLOW. Reason why the GUI clients in Windows do actually re-order ACLs so that all DENY instructions always come first, and they hide the fact order matters for the NT Kernel.
Of course hilarity ensues if you intentionally ordered an ALLOW ACL before a DENY ACL with a CLI tool and then someone just add a completely unrelated instruction via the GUI. Your careful ACL breaks as the gUI reorders everything; but at least in that case it fails safe because you end up denying access to a larger set, not allowing more access.
> The reasonable version is a "default deny" policy. Don't just deny access to the daemons, deny access to everyone by default (as POSIX ACLs and standard permissions would), and grant the daemons append-only access. If other users or groups should have read, delete, or general write access, grant it to them specifically, not as a default.
In some rare cases it may be simpler to add exceptions (all users but Joe should be able to read this file), but usually the need of an exception is a sympthom of a much deeper broken system/process elsewhere.
Posted Oct 22, 2015 20:10 UTC (Thu)
by fandingo (guest, #67019)
[Link] (3 responses)
This is entirely incorrect and undermines your entire point. ACL resolution order is an explicit feature of Linux ACLs (and traditional POSIX mode bits). Let's say I'm using traditional ACLs, and a file has permissions r-----rw-. It's owned by me, and the group doesn't matter. This is a negative policy! I am not allowed to write to this file, but others are. If the user "ACL is accidently dropped" to, say, change ownership (ACLs are a combination of a user/group object and mode bits), I end up with more permissions than I'm supposed to. This is specifically mentioned in the article.
> And many admins do not understand the complex relationship that arises when you DENY *after* an ALLOW.
How do I put this nicely? I don't want design limitations because some people are too stupid to learn the tools. That's their problem. Don't mount with the Richacl option if you don't know what you're doing.
> Reason why the GUI clients in Windows do actually re-order ACLs so that all DENY instructions always come first, and they hide the fact order matters for the NT Kernel.
I don't see why this matters at all. It's an implementation issue that the software completely handles for you, and it sounds like a good decision.
> Pure Windows semantics are even worse, and *are* counterintuitive, because not only they provide DENY ACLs, they are also *ordered*. And many admins do not understand the complex relationship that arises when you DENY *after* an ALLOW. Reason why the GUI clients in Windows do actually re-order ACLs so that all DENY instructions always come first, and they hide the fact order matters for the NT Kernel.
I don't understand what you're getting at. Back in the early NT days, yes, there were tooling problems, but those have been long corrected. Maybe you can be more specific, but this has been fixed for ages. There are some low-level APIs that allow insertion of ACLs without resolving the overall policy, but they're counter-recommended and proper versions have been around for a long time. But, hey, nothing like a Linux forum criticizing Microsoft with severely outdated information.
> In some rare cases it may be simpler to add exceptions (all users but Joe should be able to read this file), but usually the need of an exception is a sympthom of a much deeper broken system/process elsewhere.
I agree with this statement. I haven't once advocated for broad use of denial policies. Instead, I'm arguing that the ACL implementation needs to allow this expressiveness because there are legitimate situations where it's needed.
Posted Oct 25, 2015 1:44 UTC (Sun)
by idra (guest, #36289)
[Link] (2 responses)
Sorry man but you are very confused. First of all with as Posix permissions and not Posix ACLs, that said the default is no access ---, you have been given read access by turning on the r bit. Perimissions cannot be accidentally dropped so that case does not apply to the basix posix permissions. In any case if that bit were dropped you'd lose read access, whic is consistent with what I said.
> How do I put this nicely? I don't want design limitations because some people are too stupid to learn the tools. That's their problem. Don't mount with the Richacl option if you don't know what you're doing.
Tools are as good as they are usable by *normal* people. A car only a F1 drvier can use is ... how can I put it nicely ... useless to everyone but the 20 odd F1 driver on the planet, which is to say uselss.
Now RichACLs are not *that* hard, but my experience tells me that ACL systems the include ordered deny policy are a double-edged sword, and the balance between complexity and usefulness is wrongly tilted. All this said I need RichACLs to be able to reach compatibility with Windows ACLs so I'll take them as they come.
> I don't understand what you're getting at.
Sadly obvious.
> Back in the early NT days, yes, there were tooling problems, but those have been long corrected. Maybe you can be more specific, but this has been fixed for ages. There are some low-level APIs that allow insertion of ACLs without resolving the overall policy, but they're counter-recommended and proper versions have been around for a long time. But, hey, nothing like a Linux forum criticizing Microsoft with severely outdated information.
Look, those issues were not bugs that got fixed and are there no more, they are fundamental usability issues that are due to the semantics chosen. They just got "handled" by adjustment done by the GUI tools. Now there is no criticizing here *at all* (that's all in your mind pal), but only making people unfamiliar with these semantics that the *same* problems will now be found in systems used by Linux admins. They can be solved the same way, by forcing the tools to reorder the ACIs and massahe the ACLs, but afaik the tools do not do that today.
Posted Oct 25, 2015 4:30 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
No, the default is 0777. You set umask to take bits away.
Posted Oct 25, 2015 9:06 UTC (Sun)
by paulj (subscriber, #341)
[Link]
Rich access control lists
If an ACL is accidentally dropped in a Posix like system you lose access, with DENY ACLs if a DENY ACL is dropped then you gain access, which is a much worse failure mode.
Rich access control lists
Rich access control lists
Rich access control lists