summaryrefslogtreecommitdiffstats
path: root/net/mac80211/aes_ccm.c
diff options
context:
space:
mode:
authorEric Paris <eparis@redhat.com>2011-02-25 15:39:20 -0500
committerEric Paris <eparis@redhat.com>2011-02-25 15:40:00 -0500
commit0b24dcb7f2f7a0ce9b762eef0362c21c88f47b32 (patch)
tree9c7dc83e169cd4a2e5fd248e4b940f82131627b6 /net/mac80211/aes_ccm.c
parent47ac19ea429aee561f66e9cd05b908e8ffbc498a (diff)
downloadop-kernel-dev-0b24dcb7f2f7a0ce9b762eef0362c21c88f47b32.zip
op-kernel-dev-0b24dcb7f2f7a0ce9b762eef0362c21c88f47b32.tar.gz
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 'net/mac80211/aes_ccm.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud