[dm-crypt] An observation

[dm-crypt] An observation

[Bhushan Jain]

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

Re: [dm-crypt] An observation

[Milan Broz]

On 11/27/2012 06:25 PM, 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?

Hi,

AFAIK eject package was deprecated and is moved into util-linux upstream
(and almost completely rewritten).

No idea what is dmcrypt-get-device, seems like distro specific hack.
(And moreover, libblkid used in lsblk or blkid is better way to check
UUID/major:minor etc. These run in user context.)

BTW major:minor is in /sys for all block devices (lsblk uses this).

So report it to distro you see this, definitely this should
not need setuid bit!

Milan

Re: [dm-crypt] An observation

[Javier Juan Martínez Cabezón]

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.

Re: [dm-crypt] An observation

[Karl O. Pinc]

On 11/27/2012 11:25:59 AM, 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?

Speaking from ignorance, isn't there something in /sys with this
information?  If so a patch to read from that might be better.
I'm ignorant, but I've this feeling that /proc is frowned upon.

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [dm-crypt] An observation

[Bhushan Jain]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Hi Karl,
You are absolutely correct. I have submitted a patch to Debian eject package to use /sys instead as you suggested. However, somehow, it is not integrated yet. You can take a look at the thread here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695504


Thanks,
Bhushan

On Jul 9, 2013, at 10:10 PM, "Karl O. Pinc" <kop@meme.com<mailto:kop@meme.com>> wrote:

On 11/27/2012 11:25:59 AM, 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?

Speaking from ignorance, isn't there something in /sys with this
information?  If so a patch to read from that might be better.
I'm ignorant, but I've this feeling that /proc is frowned upon.

Regards,

Karl <kop@meme.com<mailto:kop@meme.com>>
Free Software:  "You don't pay back, you pay forward."
                -- Robert A. Heinlein

[-- Attachment #2: Type: text/html, Size: 4215 bytes --]