Re: [dm-crypt] An observation

["Javier Juan Martínez Cabezón" <tazok.id0@gmail.com>]

On 27/11/12 18:25, Bhushan Jain wrote:
> Hello Developers,
> 
> I am a student at Stony Brook University researching system security.
> I noticed that the only reason dmcrypt-get-device (from eject package) needs setuid privilege is to read the major:minor numbers (unless I have missed something).
> A lot of distributions (Ubuntu, Fedora, etc.) are trying to avoid use of the setuid bit because it can potentially introduce a privilege escalation attack vector.
> I think the same thing could be accomplished by exporting the major:minor device numbers through a proc file, and then eliminate the need for dmcrypt-get-device.
> I would be happy to send you a patch that does this, if there is interest.  Any comments/thoughts?
> 
> Thanks,
> Bhushan Jain
> PhD student,
> Computer Science,
> Stony Brook University
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


This has no sense, I don't see any reason to need a SYS_SETUID privilege
(there is no need of any capability to read major/minor. On devices
usually, are needed CAP_CHOWN/TTY_CONFIG with software that manage ttys
of users logged (as getty and login), CAP_SYS_RAWIO to raw access to
devices (that is read/write in brute mode as with fsck/mkfs,lilo), or
SYS_MKNOD to create devices.

You can check why does it need SYS_SETUID (or do you want mean instead
setuid as "chmod +s"?) making an strace to eject as user without setuid
and check where the final EPERM return appears, probably the reason is
because nobody can mount/umount devices without CAP_SYS_ADMIN.

As suggestion and a bit of offtopic, check rsbac kernel patch ;-)

PD: ubuntu makes use of "sudo su" in a unrestricted way so... who cares.