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]

Message-ID: <1295645825.10909.5.camel@moss-pluto>
Date:	Fri, 21 Jan 2011 16:37:05 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	jmorris@...ei.org, casey@...aufler-ca.com,
	john.johansen@...onical.com, penguin-kernel@...ove.SAKURA.ne.jp,
	takedakn@...data.co.jp
Subject: Re: SELinux/SMACK/TOMOYO: ioctl permissions handling is wrong and
 nonsensicle

On Fri, 2011-01-21 at 14:30 -0500, 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.  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!
> 
> 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....

That's unfortunate.  Prior attempt to address ioctl was here:
http://marc.info/?l=linux-security-module&m=113088357020104&w=2

Which led to the approach based on _IOC_DIR.

We could revisit that approach, or just give up and always check
FILE__IOCTL unconditionally. I don't think we want to go back to
interpreting ioctl commands in the hook, as it is a layering violation
and same ioctl command value could mean different things for different
underlying objects.

-- 
Stephen Smalley
National Security Agency

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