Re: dynamic /dev security hole?

[Albert Cahalan]

On Sun, 2004-08-08 at 11:58, Marc Ballarin wrote:
> On 08 Aug 2004 08:47:40 -0400
> Albert Cahalan <albert@xxxxxxxxxxxx> wrote:
> 
> > Suppose I have access to a device, for whatever legit
> > reason. Maybe I'm given access to a USB key with
> > some particular serial number.
> > 
> > I hard link this to somewhere else. Never mind that an
> > admin could in theory use 42 separate partitions and
> > mount most of the system with the "nodev" option. This
> > is rarely done.
> > 
> > Now the device is removed. The /dev entry goes away.
> > A new device is added, and it gets the same device
> > number as the device I had legit access to. Hmmm?
> 
> This would require (1) /dev to be inside the root filesystem and (2) users
> having write access somewhere in that filesystem.
> 
> (1) is uncommon, often a separate filesystem is used for udev
> (2) is very bad practice anyway and should never be seen on a true
> multi-user machine

Sure, blame the admins. This is like leaving landmines
in your front yard, then blaming people who step on them.

> Besides, this is nothing new. Dynamic permission updates through PAM have
> the same issue, and anyone calling themselves "admin" should be well aware
> of those issues. This is basic Unix-security, after all.

This isn't, or at least shouldn't, be basic UNIX security.

PAM should call revoke(), except that Linux still doesn't
have this system call. It's been in BSD since 4.3BSD-Reno.
Calling revoke() would fully solve the PAM problems. Any
open file descriptors would be useless. Any hard links to
the device file would get the new permission bits via the
shared inode.

IMHO, hard links need to be severely restricted by default.
It's a waste to make this even a boot option, since almost
nobody would have a legitimate need for the current behavior.
Perhaps there are other ways to deal with the problem though.

> Yet, this issue should probably mentioned in documentation. It certainly
> should be mentioned in the udev-HOWTO.

You don't have to document problems if you fix them.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/