linux-kernel - Re: [PATCH] scsi: Silence unnecessary warnings about ioctl to partition

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:	Wed, 2 May 2012 12:12:08 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Jan Kara <jack@...e.cz>, Jens Axboe <axboe@...nel.dk>,
	LKML <linux-kernel@...r.kernel.org>,
	James Bottomley <JBottomley@...allels.com>,
	linux-scsi@...r.kernel.org
Subject: Re: [PATCH] scsi: Silence unnecessary warnings about ioctl to
 partition

> Sure, but then disallowing the ioctls for processes with CAP_SYS_RAWIO
> will not cause regressions and _can_ happen.  The transition period only

The user has CAP_SYS_RAWIO, they can already do it by poking the
registers on the chip directly. It is a nonsense to attempt to block or
warn about this.

> up and implement a very restrictive filter for SCSI commands sent to
> partition.

The process has CAP_SYS_RAWIO it can already bypass any check you try and
put in place.

> The right patch is one that prepares for these step,

Doesn't look very right to me.

> http://permalink.gmane.org/gmane.linux.kernel/1254625 for example.  It
> leaves the warning only for SG_IO, and silently blocks the rest (more
> rationale in the commit message there).

Even the printk in that patch is wrong. We have capabilities. Being a
"root" user is a meaningless distinction here so your ratelimited printk
isn't just bogus - its wrong. It may have got into RHEL somehow but the
kernel QA process is a bit higher standard than this proposed patch.

A process with CAP_SYS_RAWIO has total power. It's assumed to know what
it is doing. Trying to block it doing stuff like that simply makes
authors do them via different more crass methods.

Alan
--
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/