Hi Enrico, ACLs act as whitelists that additionally let vdev equivocate about device nodes to different processes, based on the user, group, process information (PID, inode, binary path, SHA256), and requested device file. Let's work through a few examples.
Consider the following ACL, which hides both the random and urandom device nodes from user 'jude': [vdev-acl] uid=jude paths=.*random setmode=0000 Then, if I run "su jude -c ls /dev", both /dev/random and /dev/urandom will be missing from the output. Here's a more practical example that hides /dev/input/* and /dev/dri/* from every program except the X server (installed to /usr/bin/X): [vdev-acl] bin=/usr/bin/X paths=input/.*|dri/.* setmode=0666 Now, suppose I had a program called "session-ps", which took a username as an argument and printed a newline-separated list of PIDs for the processes belonging to all of that user's login sessions. For example: $ session-ps jude 28143 30888 32179 Suppose you have a multi-seat environment, and we want to forbid jude from accessing the device nodes under /dev/usb/001 since they correspond to a USB hub in a different seat. You can create an ACL to enforce this, such as this: [vdev-acl] pidlist=/usr/bin/session-ps jude paths=/dev/usb/001/.* setmode=0000 Then, if user jude runs "ls /dev/usb/001", he will see an empty directory. You can also define ACLs to present device nodes to different processes as having different owners and permission bits, depending on who's asking. For example, suppose you wanted all storage media to be writable to the fsck program, but you wanted them to appear to fsck to be owned by the 'staff' group. You could have an ACL that does this: [vdev-acl] bin=/sbin/fsck paths=/dev/s[d|r]*.* setmode=0666 setgid=staff Intuitively, the way ACLs work is as follows: 1. A request for inode data (stat, access, or readdir) comes in via FUSE. vdev sees the requesting process's UID, GID, and PID 2. vdev matches the process information, path, and inode information against its list of ACLs (looking up extra information about the process if need be) 3a. If an ACL matches, vdev alters the stat buffer for the inode accordingly and replies it to the requesting process via FUSE. 3b. If no ACL matches, vdev fails the request with ENOENT (or doesn't reply with the inode information at all). With ACLs, you can match a request on the following keys: * uid: username or user ID to match against the requesting process * gid: group name or ID to match against the requesting process * bin: path to the requesting process's binary to match against the requesting process * pidlist: a program to invoke as a subprocess that prints the list of PIDs to match against the requesting process's PID * sha256: the SHA256 hash of the requesting process's binary * inode: the filesystem inode number of the binary of the requesting process's binary * paths: a POSIX regular expression to match the request's path Before replying an inode's stat buffer, you can have the ACL perform the following alterations on it first: * setuid: set the username or user ID in the stat buffer * setgid: set the group or group ID in the stat buffer * setmode: set the mode in the stat buffer You can also have vdev take actions after it creates or removes a device node, but for your purposes I think that's the subject for a different email. Hope this helps, -Jude On Fri, Dec 26, 2014 at 8:50 AM, Enrico Weigelt, metux IT consult < [email protected]> wrote: > On 26.12.2014 10:01, Jude Nelson wrote: > > > We shouldn't have to go this far for device access control. If you > > have a script or program that can print a session's PIDs to stdout, > > you can define vdev ACL rules that will cause vdev to use this > > program to filter device nodes on a per-session basis. > > My idea was running each session in an own (partial) container, > which has its own /dev instance, and always use the same filenames > for the devices assigned to that session, whichever that might be > in the actual case. So, for example, /dev/audio would be the audio > device for *this* session. So, we dont need per-session application > configuration for such stuff. (Just have a look on how Plan9 > handles that) > > Could you explain, how vdev ACLs exactly work ? > > Maybe just let's play through certain scenarios. > > >> Yes, triggering a config reload is the first necessary step. > >> But I can also imagine an 9P-based interface (synthentic filesystem, > >> just like /proc or /sys) for directly manipulating several settings. > >> Not sure, whether that's really necessary, but we IMHO should keep that > >> in mind. > > > > Ah, I see what you mean. Since vdev is already implemented as a > > filesystem, I'll just have it expose its configuration state as a set of > > read/write files under a well-known directory. > > Yeah, that seem the right approach. > OTOH, we should have an option to mount that separately, so containers > can be setup in a way that vdev is running outside the container and > can only be configured from outside. > > > cu > -- > Enrico Weigelt, > metux IT consulting > +49-151-27565287 >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
