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: <20120502121208.3c19a9bc@pyramind.ukuu.org.uk>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ