linux-kernel - Re: SELinux/SMACK/TOMOYO: ioctl permissions handling is wrong and nonsensicle

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, 21 Jan 2011 11:50:15 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Eric Paris <eparis@...hat.com>
CC:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	sds@...ho.nsa.gov, jmorris@...ei.org, john.johansen@...onical.com,
	penguin-kernel@...ove.SAKURA.ne.jp, takedakn@...data.co.jp,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: SELinux/SMACK/TOMOYO: ioctl permissions handling is wrong and
 nonsensicle

On 1/21/2011 11:30 AM, Eric Paris wrote:
> [I've included an AA person as well in case you ever decide to try to
> mediate ioctl operations]
>
> SELinux used to recognize certain individual ioctls and check
> permissions based on the knowledge of the individual ioctl.  In commit
> 242631c49d4cf396 the SELinux code stopped trying to understand
> individual ioctls and to instead looked at the ioctl access bits to
> determine in we should check read or write for that operation.  This
> same suggestion was made to SMACK (and I believe copied into TOMOYO).
> But this suggestion is total rubbish.

Bugger bugger bugger ... (you get the idea) ... bugger.

This means calling out each and every ioctl separately,
unless someone has a magic access behavior detector for
device drivers. You can't even assume that two devices
that share an ioctl are going to do the same thing with
it. In the old Orange Book days almost half the work on
describing the access control implementation went into
iotcls and fcntls. Bugger.

What strategy is SELinux planning to take on getting the
ioctls right, and more importantly, keeping them correct
going forward?

> The ioctl access bits are
> actually the access requirements for the structure being passed into the
> ioctl, and are completely unrelated to the operation of the ioctl or the
> object the ioctl is being performed upon.
>
> Take FS_IOC_FIEMAP as an example.  FS_IOC_FIEMAP is defined as:
>
> FS_IOC_FIEMAP _IOWR('f', 11, struct fiemap)
>
> So it has access bits R and W.  What this really means is that the
> kernel is going to both read and write to the struct fiemap.  It has
> nothing at all to do with the operations that this ioctl might perform
> on the file itself!

Grrrrr.

> If anything, our logic is exactly backwards, since an ioctl which writes
> to userspace would be 'reading' something from the file and an ioctl
> which reads from userspace would be 'writing' something to the file...
>
> I'm planning to revert this SELinux commit, but I want other LSM authors
> to realize that (assuming I'm not completely off in the woods somewhere)
> you should take a look at your ioctl permissions checking as well....

Yeah. Good fun, that. Any chance we could share strategic thinking?
I hate the notion of brute forcing each ioctl, having done it in the
past for a system with lots fewer ioctls than Linux is supporting.

> -Eric

Thank you for the heads up on this. Bugger ... bugger.

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