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@xxxxxxxx > 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. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
