diff options
author | Eric Paris <eparis@redhat.com> | 2011-02-25 15:39:20 -0500 |
---|---|---|
committer | Eric Paris <eparis@redhat.com> | 2011-02-25 15:40:00 -0500 |
commit | 0b24dcb7f2f7a0ce9b762eef0362c21c88f47b32 (patch) | |
tree | 9c7dc83e169cd4a2e5fd248e4b940f82131627b6 /Kbuild | |
parent | 47ac19ea429aee561f66e9cd05b908e8ffbc498a (diff) | |
download | blackbird-op-linux-0b24dcb7f2f7a0ce9b762eef0362c21c88f47b32.tar.gz blackbird-op-linux-0b24dcb7f2f7a0ce9b762eef0362c21c88f47b32.zip |
Revert "selinux: simplify ioctl checking"
This reverts commit 242631c49d4cf39642741d6627750151b058233b.
Conflicts:
security/selinux/hooks.c
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!
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Diffstat (limited to 'Kbuild')
0 files changed, 0 insertions, 0 deletions