From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TqhWv0B7UBS for ; Tue, 27 Nov 2012 19:28:49 +0100 (CET) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 27 Nov 2012 19:28:48 +0100 (CET) Received: by mail-bk0-f50.google.com with SMTP id jf3so6230854bkc.37 for ; Tue, 27 Nov 2012 10:28:48 -0800 (PST) Message-ID: <50B50686.4070407@gmail.com> Date: Tue, 27 Nov 2012 19:29:26 +0100 From: =?ISO-8859-1?Q?Javier_Juan_Mart=EDnez_Cabez=F3n?= MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] An observation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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.