Codestin Search App

Rich access control lists

Posted Oct 21, 2015 4:00 UTC (Wed) by mathstuf (subscriber, #69389)
In reply to: Rich access control lists by JeffBai
Parent article: Rich access control lists

Yeah…it's not like one can expect user/group names and ids to match between systems anyways. And if you plop it in a system where you have root, the perms don't matter anyways. If you want real protection, put it behind LUKS or something similar.

to post comments

Rich access control lists

Posted Oct 21, 2015 7:57 UTC (Wed) by mjthayer (guest, #39183) [Link] (13 responses)

Permissions are not normally expected to afford protection against local root. More the other way round - they are a mechanism that local root can deploy to protect against non-root. From that point of view preventing file system mounting by kernels that do not understand the ACLs does make sense to me: as a hint to root that this is a bad idea, for the sort of people (lesser people like me) whose "rm" commands protect against "-r /".

Rich access control lists

Posted Oct 21, 2015 12:44 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (12 responses)

I guess. Having another system mess up your RichACLs through ignorance (due to the kernel ignoring them) isn't nice. Malice isn't something that would have been prevented anyways.

Can an old kernel at least mount the filesystem read-only?

Rich access control lists

Posted Oct 21, 2015 15:01 UTC (Wed) by felixfix (subscriber, #242) [Link] (9 responses)

Read-only would still allow ignoring anti-read permissions.

Rich access control lists

Posted Oct 21, 2015 15:16 UTC (Wed) by niner (guest, #26151) [Link] (8 responses)

Which is irrelevant. File permissions have never protected in any way from physical access. If you can boot the machine with an older kernel, it's safe to assume, that you have root or even physical access. Both is enough to circumvent any file permissions anyway.

If you're not improving security by denying read only mount and you're not preventing any erroneous modifications, then why prohibit it?

Rich access control lists

Posted Oct 21, 2015 16:23 UTC (Wed) by felixfix (subscriber, #242) [Link] (7 responses)

Do I misunderstand you? Are you actually saying that because root and physical access can override any file permission security, get rid of file permissions?

Rich access control lists

Posted Oct 21, 2015 16:34 UTC (Wed) by niner (guest, #26151) [Link] (5 responses)

I honestly don't know how my comment can be interpreted in that way, but it obviously can :)
So, no, it absolutely was not meant in that way.

If you as an attacker want to circumvent file permissions and the way you do it is by booting a different kernel, no feature bit in the world can stop you. To boot the other kernel you either have physical access to the media, or at least root access to the machine. So the feature bit is completely worthless as protection.

File permissions are a security device in a running system. Once the system is not running anymore be it because the drives are removed or the system is rebooted, the security is gone. That's why we have disk encryption. Disk encryption won't help you if the attacker breaks into the running system. File permissions may. But disk encryption helps you where file permissions won't: with offline attacks.

Rich access control lists

Posted Oct 21, 2015 16:55 UTC (Wed) by bfields (subscriber, #19510) [Link] (2 responses)

Right, understood, but this is more something to keep administrators from shooting themselves in the foot, like warnings on rm -rf /, or -EBUSY on attempts to mount the same block device twice.

If you're mounting an ACL-protected filesystem on a multi-user system that isn't capable of enforcing them then there's a reasonable chance you're just making a mistake.

I assume there's some way to clear the flag if you still really want to do it.

Rich access control lists

Posted Oct 21, 2015 23:06 UTC (Wed) by neilbrown (subscriber, #359) [Link] (1 responses)

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

Rich access control lists

Posted Oct 22, 2015 1:52 UTC (Thu) by bfields (subscriber, #19510) [Link]

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

Posted Oct 21, 2015 23:03 UTC (Wed) by smoogen (subscriber, #97) [Link] (1 responses)

You just have never system administered a system where the owner wanted everything 7777 root:root because file permissions are evil.. that was exactly the same argument on why he ( a PHD of many sciences ) didn't think any file perms were needed. [And I have heard it enough times that you can never tell if a person is wanting to get rid of them all or just with why this shooting you in the foot prevention isn't really good. ]

Rich access control lists

Posted Oct 22, 2015 0:15 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> 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

Posted Oct 21, 2015 16:35 UTC (Wed) by mjthayer (guest, #39183) [Link]

I could see sense in optionally allowing root to mount the file system read-only (or read-write for that matter), if it required them to add an "I really meant this" parameter. My understanding of the article is that this is not planned.

Rich access control lists

Posted Oct 28, 2015 10:24 UTC (Wed) by Seegras (guest, #20463) [Link] (1 responses)

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

Posted Oct 28, 2015 23:55 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

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