linux-kernel - Re: PATCH: scsi: make scsi reset permissions more relaxed (RFC)

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]

Date:	Fri, 30 Aug 2013 14:18:04 +0200
From:	Hannes Reinecke <hare@...e.de>
To:	Marcus Meissner <meissner@...e.de>
Cc:	JBottomley@...allels.com, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: PATCH: scsi: make scsi reset permissions more relaxed (RFC)

On 08/30/2013 02:04 PM, Marcus Meissner wrote:
> Hi folks,
> 
> cdrecord wants to whack the CD drive with a SCSI RESET ...
> 
> So far SCSI RESET can be done at 4 levels (target, device, bus, host)
> and all 4 are checked for CAP_SYS_ADMIN / CAP_SYS_RAWIO.
> 
> 
> As the cdrecord author wants special permissions for cdrecord, readcd ,
> cdda2wav to allow it to send SCSI RESET commands I was wondering if
> relaxing the permission is a potential idea?
> 
> This would allow SCSI reset on target/device if a local user
> gets regular access to a SCSI device (via udev acls etc.)
> 
Hmm. Device and target reset are typically implemented at the
transport level (SCSI itself doesn't have any commands for this).
So it should be possible to inject them via bsg, and as such should
have the same restrictions as bsg has.
Assuming that sg and bsg follow the same rules the patch should be okay.

> 
> (I know that the actual reset code will fall back into the chain
>  target -> device -> bus -> host resetting if one fails.)
> 
Actually, it doesn't. sg_reset_provider() will just call the
individual function.

If the function fails _and_ there are commands send to the device
then the error handling will kick in, but it won't be triggered
directly.
Not sure if that makes a difference, though.

> Signed-off-by: Marcus Meissner <meissner@...e.de>
> 
Acked-by: Hannes Reinecke <hare@...e.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@...e.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/