Hi Enrico,

> I dont believe ACLs are a good idea anyways. They introduce yet another
> (orthogonal) dimension to the system, so heavily increase management
> complexity. For example, it's hard to trace problems that way, if /dev
> layout heavily depends on the calling process.

I don't disagree with you, especially since namespacing will be necessary
when the same device node in each session must refer to a different
device. However, as I mentioned in an earlier email, solving the problem
of per-process access control by giving each session its own namespace
isn't always viable, particularly on OpenBSD (which has no containerization
support beyond chroot, and chroot isn't particularly useful for containing
processes). It's also not clear to me that the maintenance burden would be
reduced versus using ACLs, since a strategy for populating a given
session's /dev and keeping it up-to-date with hotplug events would probably
be comparably complex to vdev's ACL system (and this is on top of the
container lifecycle management code you'd have to write).

Also, you shouldn't have to use vdev's ACLs if you don't want to :) It's
perfectly valid to have vdev report all device nodes by default and take no
filtering actions, just like how udev would (definitely makes tracing
problems easier). I would never want to force you or anyone to use ACLs if
you didn't need them, since they're only one mechanism of many that can be
used to achieve the same end.

> I'd rather raise the question whether that's useful at all.

There was an LWN article on this a while back [2]. The examples provided
there are as follows:
* If the login program could revoke() the tty device node before prompting
the password, this attack vector would be removed (assuming the revoke()
implementation didn't affect file descriptors in the calling process).
This also applies to X11, which could revoke() the video device file prior
to setting it up.
* Suppose a process has open files in a filesystem you're trying to
unmount. You could revoke all files in the filesystem prior to trying to
umount() it.

I can think of other ways to solve these problems without revoke() (e.g.
fuser will tell you who's accessing a file, allowing you to take further
actions like killing the offending processes); maybe that's why it didn't
make it into the kernel?

-Jude

[1] https://qubes-os.org/
[2] http://lwn.net/Articles/192632/


On Sat, Jan 3, 2015 at 12:22 AM, Enrico Weigelt, metux IT consult <
enrico.weigelt@???> wrote:

> On 02.01.2015 20:43, Jude Nelson wrote:
>
> Hi,
>
> > I should point out, the ACL criteria for matching processes do not all
> > have to be specified, specifically for the reason you point out. Using
> > the SHA256 to match the process should be a tool of last resort, useful
> > only when the executable's path, inode number, and PID listing commands
> > are unreliable (for example, a program that runs from an arbitrary
> > location but for which no PID listing program can be created).
>
> I dont believe ACLs are a good idea anyways. They introduce yet another
> (orthogonal) dimension to the system, so heavily increase management
> complexity. For example, it's hard to trace problems that way, if /dev
> layout heavily depends on the calling process.
>
> Instead I'd suggest using chroot's / namespaces for isolation.
>
> > As much as I would like to revoke file descriptors, I'm afraid there's
> > no way to do this that I know of without the kernel's help (but I'd love
> > to learn of one).
>
> I'd rather raise the question whether that's useful at all.
> IMHO, there're two main scenarios:
>

> a) remaining processes after logout
>    --> should be killed anyways (eg. via cgroups, etc)
> b) physical devices should be assigned temporarily to some session, eg.
>    when switching VTs.
>    --> we need some proxy server for that, which handles the switchover
>        gracefully

>
> For most devices, which unprivileged users get access to (eg. audio),
> IMHO should be routed via some server anyways - (most) other devices
> should only be available to special privileged users (eg. DRI for
> Xserver, etc).
>
>
> cu
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>