linux-kernel - Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130523005431.GA17291@mtj.dyndns.org>
Date:	Thu, 23 May 2013 09:54:31 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org
Subject: Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization
 of the SG_IO command whitelist (CVE-2012-4542))

On Thu, May 23, 2013 at 07:17:37AM +0900, Tejun Heo wrote:
> > No, it doesn't.  You can use SCM_RIGHTS, and pass a file descriptor for
> > the device node to an unprivileged program.  You can choose the
> > users/groups that are allowed to access the device.  In either case, the
> > privileged action is limited in time or in scope.
> > 
> > The count-me-out knob affects all processes that use the device node,
> > and won't be cleaned up properly if you SIGKILL the (privileged)
> > process that sets it.  So if you can avoid it, you should.
> 
> Then let's make it fit the use case better.  I really can't see much
> point in crafting the cdb filter when you basically have to entrust
> the device to the user anyway.  Let's either trust the user with the

One more thing, is it really necessary to have finer granularity than
provided by file permissions?  What would be the use case?  Do you
expect to have multiple - two - differing levels of access with and
without SG_IO?  Note that, for the same user, it's pointless to give
out SG_IO access to processes while denying for other processes.  As
long as ptrace can be attached, hijacking such fd is easy.  Making it
per-device should be suitable enough, no?

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/