LWN: Comments on "Rich access control lists"

Rich access control lists

bfields — Tue, 20 Aug 2019 16:43:46 +0000

Eh, this is a pretty minor nit.

If you want to complain about some flavor or ACLs being too complicated, I think there are better places to start.

Here, honestly, I think we should probably just fix the Linux ACL implementation, and I doubt anyone would notice the change.

I've been meaning to write a patch and just haven't gotten around to it. It's not something people run across in practice so a little hard to prioritize.

Rich access control lists

Cyberax — Thu, 15 Aug 2019 18:36:54 +0000

A great example why RichACLs and ACLs in general are a bad idea and should just stay away from the kernel.

Rich access control lists

pgoetz — Thu, 15 Aug 2019 18:02:23 +0000

It is so freaking depressing that Jon published this article in 2015 and we STILL don't have RichACLs in the linux kernel. For people like myself who have to deal with real world security issues in a heterogeneous compute environment, this is a serious impediment to satisfying fairly reasonable security requests.

Rich access control lists

pgoetz — Thu, 15 Aug 2019 17:59:50 +0000

An example is provided here: https://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03...

There is one extremely minor inaccuracy in this mapping: if a
requester that is a member of more than one group listed in the ACL
requests multiple bits simultaneously, the POSIX algorithm requires
all of the bits to be granted simultaneously by one of the group
ACEs. Thus a POSIX ACL such as

ACL_USER_OBJ: ---
ACL_GROUP_OBJ: ---
g1: r--
g2: -w-
ACL_MASK: rw-
ACL_OTHER: ---

will prevent a user that is a member of groups g1 and g2 from opening
a file for both read and write, even though read and write would be
individually permitted.

The NFSv4 ACL permission-checking algorithm has the property that it
permits a group of bits whenever it would permit each bit individu-
ally, so it is impossible to mimic this behaviour with an NFSv4 ACL.

History Repeats

Wol — Sun, 01 Nov 2015 02:25:07 +0000

Pr1mos was a Multics derivative. And it had ACLs since v19.4 (actually, 19.0 but they were broken quite bad), and that came out about 1984. I can't remember the details, but I know I came across a v19.2 system (very unusual), and when I tried to use some commands they crashed the system ...

Cheers,
Wol

Rich access control lists

Wol — Fri, 30 Oct 2015 17:17:35 +0000

> > Being accepted into a group has positive connotations; rejection is negative.

> What about prison inmates? What about people on no-fly lists? Groups have negative connotations and restrict behavior all the time.

You missed that sentence of the OP ... Prison inmates aren't ACCEPTED, they're PLACED. Likewise the no-fly. You can split groups into two types, the ones you JOIN, and the ones that other people PUT you in. Yes, the latter are normally places you'd rather not be.

But if you treat ACLs as the former type of group, then it makes everything a lot simpler.

Cheers,
Wol

Rich access control lists

fest3er — Thu, 29 Oct 2015 14:56:29 +0000

Sounds like a firewall. First apply blacklists (those individuals and groups who are to be denied access at all times). Next apply whitelists (those individuals and groups always allowed access). Then apply mixed allow/deny rules that may allow access or may deny access. Finally, if access hasn't already been allowed or denied, deny it. Easy concept. Non-trivial implementation.

Rich access control lists

Wol — Thu, 29 Oct 2015 14:13:38 +0000

> I worked with Windows ACLs extensively. That's the reason why I hate complicated permission systems.

As others have said, it's just so complicated ...

And I know I've said it before, but Pr1mos just had read, write, use. For files or directories. So that makes six different permissions. And using them was simple - if your user was explicitly specified, that was what you got. If you weren't explicitly named, but your groups were, those permissions were added together. And if neither your user, nor a group you were in, was specified, you just got the default permissions. Very simple, very easy to understand.

Cheers,
Wol

Rich access control lists

mathstuf — Wed, 28 Oct 2015 23:55:00 +0000

Right. So why is read-only mounting not allowed?

Rich access control lists

Seegras — Wed, 28 Oct 2015 10:24:38 +0000

The problem is not mounting filesystems and ignoring the permissions the ACLs specify. The problem is having something mount a filesystem containing ACLs and modifying the contents, thereby DESTROYING the ACLs already specified in the filesystem.

You don't mind something ignoring the ACLs, but you don't want it to delete them. ACL-insensitive-but-ACL-preserving ;)

Rich access control lists

skissane — Sun, 25 Oct 2015 22:48:28 +0000

> With one obscure exception, all POSIX ACLs can be mapped onto NFSv4 ACLs
And what is that "one obscure exception"? My curiosity has been piqued.

Rich access control lists

paulj — Sun, 25 Oct 2015 09:06:24 +0000

Bizarre, why use order-significant ACLs if to make them usable tools must then - all, consistently! - normalise the order somewhat?

Rich access control lists

mathstuf — Sun, 25 Oct 2015 04:30:34 +0000

> that said the default is no access ---

No, the default is 0777. You set umask to take bits away.

Rich access control lists

idra — Sun, 25 Oct 2015 01:44:39 +0000

> 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.

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.

Rich access control lists

jubal — Sat, 24 Oct 2015 17:20:46 +0000

I guess you wouldn't like pam_access either.

Rich access control lists

nevyn — Fri, 23 Oct 2015 19:59:41 +0000

Speed should override any other concerns here, look at the time of a large rsync on files with just modes vs. those which have xattrs or ACLs.

Rich access control lists

Cyberax — Thu, 22 Oct 2015 22:58:35 +0000

No. Complex LSMs proved to be a total failure - NOBODY understands how SELinux works, so on most systems it just sits idly and eats resources.

At least with modebits I can understand what's happening immediately. With Windows ACLs you can't do that - you have to carefully evaluate the rules, keeping their order in mind. POSIX ACLs are ok-ish, they at least play nicely with the regular Unix permissions.

And your examples are so far extremely poor. If you need to constrain a daemon to use only O_APPEND - then write an LSM module for that. No need at all to rape file permissions. And if you are doing it over NFS then get a proper rsyslog, for FSM's sake.

So what are other examples, apart from the contrived O_APPEND?

Rich access control lists

fandingo — Thu, 22 Oct 2015 20:10:30 +0000

> 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.

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.

Rich access control lists

idra — Thu, 22 Oct 2015 18:55:07 +0000

>> It's only counter-intuitive because that's what you're used to. If you learned on systems with NFSv4-style ACLs, this wouldn't be confusing.
> 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.

Rich access control lists

fandingo — Thu, 22 Oct 2015 18:26:15 +0000

> Personally, I tend to think of those from the opposite (positive) point of view. The group of members of society in good standing; the group of people granted the privilege of flying. (Which should be the same as the first group, but that's a whole other discussion...)

What a coincidently self-serving stance, but it's still a tortured viewpoint that's incorrect. It simply doesn't comport with reality. The government does not maintain a list of people authorized to fly, so there's no group there. They do maintain list for no-fly and mistakenly-no-fly people. Same thing for inmates; there's no list of free civilians, but there are lists (per jurisdiction) of those incarcerated. To get a list of free people, you need to derive that from the difference between the census and those in prison. The implementation dictates POV.

> Obviously any particular set of rules can be implemented either way. The problem mainly arises when you add new users to the system. In a pure whitelist scenario, you only have to decide what the new user *should* have access to. Anything you don't grant access to is off-limits, which is a safe default. If you build your system around DENY rules then you also have to make sure the new user gets added to the appropriate blacklists, or they'll have more access than you intended.

Meh, that's what administrative user-management tools are for. Let the software handle it.

Rich access control lists

nybble41 — Thu, 22 Oct 2015 18:18:00 +0000

> I'll note that even on classic mode bits, a group can restrict access.

Right, and I don't consider that intuitive either. The effective permissions should be a bitwise-OR of the applicable fields, not simply the first match.

Rich access control lists

nybble41 — Thu, 22 Oct 2015 17:50:27 +0000

> What about prison inmates? What about people on no-fly lists?

Personally, I tend to think of those from the opposite (positive) point of view. The group of members of society in good standing; the group of people granted the privilege of flying. (Which should be the same as the first group, but that's a whole other discussion...)

Obviously any particular set of rules can be implemented either way. The problem mainly arises when you add new users to the system. In a pure whitelist scenario, you only have to decide what the new user *should* have access to. Anything you don't grant access to is off-limits, which is a safe default. If you build your system around DENY rules then you also have to make sure the new user gets added to the appropriate blacklists, or they'll have more access than you intended.

Rich access control lists

eternaleye — Thu, 22 Oct 2015 17:36:03 +0000

> Being a member of a group is a privilege, not a burden. Being accepted into a group has positive connotations; rejection is negative.

I'll note that even on classic mode bits, a group can restrict access. See above on how "the other permission is not even consulted if user or group match" - because of that, u=rw,g=,o=r is an entirely valid permission that denies read only for a specific group.

Rich access control lists

bfields — Thu, 22 Oct 2015 02:05:12 +0000

There's absolutely no reason why this needs to be done in POSIX bits, though. If the file/file-system is Richacl enabled, translate the chmod(2) (or the variety of other POSIX ACL syscalls) to Richacl -- solely operating on the Richacl xattrs. The POSIX bits, then, are just a virtual representation of Richacl xattrs.

Note that POSIX ACLs are quite a bit more complicated than mode bits, I wouldn't lump them together.

You can think of Andreas's patches as already implementing mode bits on top of Richacls, if you'd like. I'm not sure exactly what your complaint is there.

Going further and implementing full POSIX ACLs on top of Richacls would also be possible, but quite complicated, and I think Andreas's choice not to do that is reasonable.

Rich access control lists

bfields — Thu, 22 Oct 2015 01:52:18 +0000

You are showing your age!

Already??

It has been for many years that trying to mount an already-mounted block device simply creates a bind-mount. You do get -EBUSY if you mount a block device on a directory where the same block device is mounted, but I think that is just to stop repeated "mount -a" from flooding the mount table.

Sigh; I was paying attention to this, honest! Thanks for the correction.

Rich access control lists

fandingo — Thu, 22 Oct 2015 01:50:17 +0000

Sure, if you want to do that, although some file systems have xattr length limitations. I'd treat ACLs the same as LSMs: Pick anyone you want (and stack them if you like and support is implemented). The data will be stored in xattrs defined by that ACL module, and a file system feature flag can be used to force (or indicate if a bypass kernel cmdline / config option is set) a kernel to use that ACL module.

Nonetheless, I doubt you'd have many people in such a scheme. But, let's dial it back from absurdity.

Rich access control lists

Cyberax — Thu, 22 Oct 2015 01:30:34 +0000

And to guarantee that the entries are also semantically correct, perhaps we can add another permission to attach an XML (or even ASN.1) schemas to files?

Of course, some people might also forbid any file activity on Sundays, so we need a special permission for that as well.

Rich access control lists

fandingo — Thu, 22 Oct 2015 01:13:45 +0000

I neither said nor implied it did. IO synchronization is a separate problem. Perhaps down the road, they can add additional Richacl types (unsigned int leaves a lot of available flags) for open(2) modes like O_SYNC (and other associated syscalls) to allow Richacl policy to require or prohibit that option.

> so I'm curious to see the actual systems that depend on it.

I'm not sure any piece of software itself could "depend" on it. From the software's perspective, it's just eliminating extraneous syscalls and mode flags. It's the software distribution's (or perhaps the adventurous sys admin's) job to write and distribute a policy. The policy separation and delegation to distributions is same as SELinux.

Rich access control lists

Cyberax — Thu, 22 Oct 2015 01:09:21 +0000

> What's the insanity? If you don't want to express anything beyond POSIX ACLs, it's nothing more than a storing data in a different format.
And a translation layer. And significant additional overhead (xattrs are SLOW compared to the fastpath).

So no, it's definitely not something I'd want to ever see close to my systems.

Rich access control lists

fandingo — Thu, 22 Oct 2015 00:59:32 +0000

What's the insanity? If you don't want to express anything beyond POSIX ACLs, it's nothing more than a storing data in a different format. Plus, it's not some brand-new format; it's using well-tested xattrs.

Rich access control lists

fandingo — Thu, 22 Oct 2015 00:56:18 +0000

> but worth how much in the face of the added complications, bugs and performance hit?

It's worth 42. I don't know how to answer the obviously loaded, rhetorical question. You'll need to offer data about performance implications before I'll get into that topic; it's just FUD otherwise.

> Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

For the most part, this isn't something that applications will interact with at all. (I suppose beyond EACCESS when there is a violation, but they have to deal with that anyways.) It will be handled just like SELinux policy: The Linux distribution writes and maintains it.

There is specialized software that may need to interact with Richacl specifically, but I just don't see it being a major problem. The only places where it may cause a problem is when a project is sloppy with it's open(2) mode flags, which should be tightened regardless of Richacl. If a piece of software is diligent, writing a policy for that software package isn't any challenge.

Rich access control lists

Cyberax — Thu, 22 Oct 2015 00:29:50 +0000

As far as I know, no HDFS implementations depend on filesystem-level append-only permissions.

Rich access control lists

smckay — Thu, 22 Oct 2015 00:27:59 +0000

Does HDFS count? As appending is the only kind of writing you can do. ;)

Rich access control lists

Cyberax — Thu, 22 Oct 2015 00:19:01 +0000

> I'd argue that we'd be far better off switching to native Richacl solely. Continue to support traditional POSIX ACL syscalls, but they all get translated to Richacl for both policy evaluation and storage.
I vomited a little. Personally, I'm not against some FS-specific ACL perversions. Just wash your hands after using it.

But forcing your insanity on others? No way.

Rich access control lists

Cyberax — Thu, 22 Oct 2015 00:17:41 +0000

> You think containers are a contrived example? There are plenty of situations that need WORM semantics where append-only is important. Any transaction processing system that appends to a file would benefit from that security.
If you want real WORM for auditing purposes then file permissions are not enough.

Append-only mode also does not guarantee atomicity, so I'm curious to see the actual systems that depend on it. I'm not aware of anything non-trivial.

Rich access control lists

Cyberax — Thu, 22 Oct 2015 00:15:55 +0000

> You just have never system administered a system where the owner wanted everything 7777 root:root because file permissions are evil.
So pretty much every system out there?

XKCD explains that succinctly: https://xkcd.com/1200/

Rich access control lists

dlang — Thu, 22 Oct 2015 00:09:48 +0000

> Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

advantageous, yes

but worth how much in the face of the added complications, bugs and performance hit?

Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

Rich access control lists

fandingo — Thu, 22 Oct 2015 00:04:49 +0000

> Anything important like that sort of log data, I want off on a separate machine.

I already addressed this in a previous comment.

>> Additionally, you'd use this exact same append-only policy on the files that syslog does write, making your point moot.

Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

Rich access control lists

dlang — Wed, 21 Oct 2015 23:19:15 +0000

If you trust the kernel and permissions to protect the file from being truncated once you have a malicious actor taking over your binary, you have a lot more trust than I do.

Anything important like that sort of log data, I want off on a separate machine.

Rich access control lists

neilbrown — Wed, 21 Oct 2015 23:06:52 +0000

(off-topic tangent)
> -EBUSY on attempts to mount the same block device twice.

You are showing your age! It has been for many years that trying to mount an already-mounted block device simply creates a bind-mount.
You do get -EBUSY if you mount a block device on a directory where the same block device is mounted, but I think that is just to stop repeated "mount -a" from flooding the mount table.