You are not logged in.

#1 2018-08-17 16:43:29

eomanis
Member
Registered: 2013-04-17
Posts: 50

Peer review - inherit-acl: How bad an idea is this application?

I have a home server, which among other things hosts an FTP server that chroots all its users into /media/data/ftp.
In this shared FTP directory there are subdirectories pertaining to various subjects; to gain access to such a subdirectory a user must be a member of the respective subject group. Access is controlled using Access Control Lists (ACL).
For example, there may be a directory "some-event" where all users that took part in the event may upload and share pictures and videos they took.

When I do management stuff on that server I use a local management user. I might, using this user, move files and directories around, for example from elsewhere into /media/data/ftp. The server has a large file system mounted at /media/data where everything is kept, so moving things is quick, but every time I move something the moved item's user/group/permissions/acl stay the same, so after moving I have to wield chown/chgrp/chmod/setfacl wildly on the moved items so that they are properly accessible by the other users. I do have helper scripts for some of the directories on /media/data that recursively repair these permissions, but I cannot let them run for each item I move, because they take quite some time to complete and bog down the system something fierce. And I have better things to do than to gain root access and type in all those commands – especially using setfacl is rather time-consuming.

So what I wanted, and what this is about, is a context menu entry in my file explorer "Apply ACL of parent directory" that I can use on items that I just moved.
I didn't find a ready-made solution so I wrote inherit-acl.

Now, changing things like the owning user or group, the permissions, or the ACL on an item requires root privileges – maybe not in all cases, depending on the item, but I want the tool to function reliably. The bottom line is that regular users should be able to run inherit-acl with root privileges. This would be risky though, because the user may call it on stuff in /etc or such, which smells like a big fat security problem.
As a mitigation, the systems administrator can define user-specific parent directory whitelists below which a user may apply inherit-acl; sudo is used to enforce the whitelists.

If by now there is an alarm going off in your head because you just thought of n ways a user might be able to hack the system using inherit-acl, this is why I posted this topic, to get some more insights into the security risks involved.
For starters, I suspect hardlinks may be problematic, then I also might have written weak bash code that could be tricked with some crafted paths, or whatever. Corner cases are the bane of systems security.

Here's how inherit-acl does its stuff:

inherit-acl 0.1.0

Usage:
inherit-acl path [path]...

For each given path, recursively applies the path's parent directory's
 - owning user
   (chown --reference parentDir --recursive --no-dereference -- path)
 - owning group
   (chgrp --reference parentDir --recursive --no-dereference -- path)
 - permissions
   (chmod --reference parentDir --recursive -- path)
 - default ACL
   (getfacl (...) -- parentDir | (...) \
   | setfacl --recursive --physical --set-file - -- path)

Runs its companion application "inherit-acl-run" as root using sudo;
the calling user's login name is given as the 1st argument:

  $ sudo inherit-acl-run userLogin /path /another/path

Sudo is not used if "inherit-acl" is already running as root.

Access control is supposed to be done with sudo, e.g. to let the user
"someuser" run the companion application as root with that user
login only, an /etc/sudoers line like this is suggested:

  someuser ALL=(root) NOPASSWD: /usr/bin/inherit-acl-run someuser *

This way, user "someuser" is allowed to run the companion
application as root, but only with user login "someuser" as first
argument.

The companion application uses the user login to determine a
user-specific parent directory whitelist; paths whose parents are not
whitelisted will be skipped.

The whitelists are configured in the configuration file
"/etc/inherit-acl.conf" in the form of an associative bash array
having the user logins as keys and newline-separated lists of valid
parent directories expressed by their absolute paths as values:

  parentDirWhitelist["someuser"]='
  /media/data/shared
  /media/data/transfer
  /media/data/ftp
  '

Empty lines in the array's values are ignored.
This whitelist would, for user "someuser", have this effect for
these paths given as arguments:
 - FALSE: "/media/data" (parent "/media" not whitelisted)
 - FALSE: "/media/data/shared" (parent "/media/data" not whitelisted)
 -  TRUE: "/media/data/shared/someDir"
 -  TRUE: "/media/data/shared/someDir/someSubdir"

Please be aware that although symbolic links will not be followed,
clever users may use hardlinks to circumvent their whitelist and process
any other file they may hardlink below their whitelisted parent
directories.
Assuming that hardlinking directories is not possible, and that hardlink
protection is enabled (check "/proc/sys/fs/protected_hardlinks"), this
encompasses all files that a user has write access for, and that reside
on the same file system as a whitelisted parent directory.
If this risk is unacceptable bind mounts might be used to prevent such
hardlinking, as it appears that they do not allow hardlinking to targets
beyond their mount point. 

Last edited by eomanis (2018-08-17 16:44:28)

Offline

#2 2018-08-21 20:48:40

Awebb
Member
Registered: 2010-05-06
Posts: 6,272

Re: Peer review - inherit-acl: How bad an idea is this application?

Some inotify magic and a systems service is out of the question?

Offline

#3 2018-08-23 16:56:13

eomanis
Member
Registered: 2013-04-17
Posts: 50

Re: Peer review - inherit-acl: How bad an idea is this application?

Awebb wrote:

Some inotify magic and a systems service is out of the question?

Well now that would be my Holy Grail. The real one, not one of those that melt your face off.
Such a service would also take care of situations like an FTP user uploading a file into a private directory and then moving it to a public share directory.

I actually looked a bit into inotify before I started, but writing something like that seemed to be a rather daunting task for me. I guess bash won't do, and I haven't written anything in C yet. So I settled for the half-assed manual approach.

You wouldn't happen to know about such a service that already exists?
I suspect there would be demand for such a solution in more professionally managed Linux environments such as in companies.

Offline

#4 2018-08-23 17:00:56

Alad
Wiki Admin/IRC Op
From: Bagelstan
Registered: 2014-05-04
Posts: 2,407
Website

Re: Peer review - inherit-acl: How bad an idea is this application?

I actually looked a bit into inotify before I started, but writing something like that seemed to be a rather daunting task for me. I guess bash won't do, and I haven't written anything in C yet. So I settled for the half-assed manual approach.

You can use inotifytools, so bash will work. smile


Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby

Offline

#5 2018-08-23 19:41:18

Awebb
Member
Registered: 2010-05-06
Posts: 6,272

Re: Peer review - inherit-acl: How bad an idea is this application?

I'm still not sure why you go the extra mile here.

Use setgid on the directory. The files in that directory should then always inherit the group of the directory, unless your ftp server (whichever that is) overrides it. Unfortunately the setuid bit on directories is being ignored on Linux (but accepted on some BSD and even the default in other UNIX flavors). The setgid is a bit, so it stays and is not limited to the shell. Unless your ftp server does anything weird, the group will be inherited from the folder. That's what you're after, I think, since your users access files by group. Then you'll have a cronjob, that evens the uid of files and folders periodically, because they are not mission critical. You should be able to set the default rwx stuff in your ftp server, so all you need to worry, are the uploaded files' uid's. If you don't want users to know, who uploaded what, then inotify is your friend. If you don't care, have a cleanup script run, say, once an hour, once a day, depending on your needs.

Offline

#6 2018-09-03 10:55:35

eomanis
Member
Registered: 2013-04-17
Posts: 50

Re: Peer review - inherit-acl: How bad an idea is this application?

Awebb wrote:

I'm still not sure why you go the extra mile here.
Use setgid on the directory. (...)

Thanks for the suggestions, but well, the internet is littered with examples of setgid and cronjob hackery "solving" only specific problems in what I perceive to be unelegant, sloppy and possibly insecure ways, and that are not readily applicable to my situation.
For starters, I have distinct read and read-write permission groups on the event directories, so the single owning group inherited with setgid is insufficient.

On a side note, for me setgid smells like a desperate band-aid slapped onto the sorely lacking user-group-other "classic" permissions mechanism that leaves so much to be desired.

No, my ambition here is to find the clean, elegant solution to the general problem and nothing less, the general problem being finding a way to have reliable, no-gotchas, no-compromise self-maintaining path-based permissions on Linux.
Personally I find it mind-boggling that there isn't a well-known solution for this yet.

Offline

#7 2018-09-03 11:27:36

Awebb
Member
Registered: 2010-05-06
Posts: 6,272

Re: Peer review - inherit-acl: How bad an idea is this application?

The reason there is no well-known solution to this problem is, that this is not one problem, but an infinite number of special cases. I just found it difficult to come from a manual right click in a graphical file manager to the clean, elegant solution. :-P

Offline

#8 2018-09-03 13:40:46

eomanis
Member
Registered: 2013-04-17
Posts: 50

Re: Peer review - inherit-acl: How bad an idea is this application?

Awebb wrote:

I just found it difficult to come from a manual right click in a graphical file manager to the clean, elegant solution. :-P

You're right, the way inherit-acl is implemented it is mostly a stop-gap measure. You know how it is in software development: First, make it work. Then, make it work well wink
It seems to work though, and reliably. For one thing, you don't have to worry about umask screwing you over, or chmod masking out some of your precious ACL.

A system service that can be configured to automatically do that very same thing below certain parent directories, such as you proposed – that would be the real solution for, I think, any kind of shared directory structure, such as the mentioned FTP server.
Possibly with more configuration options, such as which of the four aspects (user, group, perms, ACL) to apply on a per-parent-directory basis.

Offline

#9 2018-09-03 17:24:07

Awebb
Member
Registered: 2010-05-06
Posts: 6,272

Re: Peer review - inherit-acl: How bad an idea is this application?

Beyond that... have we helped you or are you still without a solution?

EDIT: Skip that, the topic was "peer review". You HAVE a solution :-)

Last edited by Awebb (2018-09-03 17:24:35)

Offline

Board footer

Powered by FluxBB