linux-kernel - 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1295638239.3403.15.camel@localhost.localdomain>
Date:	Fri, 21 Jan 2011 14:30:35 -0500
From:	Eric Paris <eparis@...hat.com>
To:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Cc:	sds@...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: SELinux/SMACK/TOMOYO: ioctl permissions handling is wrong and
 nonsensicle

[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....

-Eric

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