On Sat, Jan 03, 2015 at 01:27:38AM -0500, Jude Nelson wrote:
> 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).

It looks as if this whole discussion is in the direction of building a
capability architecture on top of Linux. I'm not sure this isn't a
much greater change than imposing systemd. If you want such a thing,
better to switch to an OS that does this natively, such as, perhaps,
inferno.

It is very convenient within Linux to be able to switch to superuser
mode using su or sudu to perform an administrative action when needed,
without the entire namespace changing drastically. What? Suddenly
all my device names have changed? How do I know what I was having
trouble with as an ordinary user? Or else, if nothing changes, What?
as root I still can't access the devices I need that the ordinary user
couldn't name?

But yes, of course, my home directory should switch to root's.

No. It's privileges that should determine what I have access to, not
my namespace.

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

What if I'm currently logged in through a ssh shell and using
that connection to su into another user's account? Is there a
relevant tty to revoke?

> * 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?

Finding out which processes are accessing a file and manually shutting
them down cleanly might be a lot safer than either revoking or killing the
processes.

-- hendrik