[dm-crypt] An observation
Javier Juan Martínez Cabezón
tazok.id0 at gmail.com
Tue Nov 27 19:29:26 CET 2012
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?
> Bhushan Jain
> PhD student,
> Computer Science,
> Stony Brook University
> dm-crypt mailing list
> dm-crypt at saout.de
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.
More information about the dm-crypt