With the sysctl cleanups sysctl is not really a part of proc
it just shows up there, and any path based approach will not
adequately describe the data as sysctl is essentially a
union mount underneath the covers. As designed this mechanism
is viewer dependent so trying to be path based gets even worse.
However the permissions in sys_sysctl are currently immutable
and going through proc does not change the permission checks
when accessing sysctl. So we might as well stick with the well
defined sysctl sid, as that is what selinux uses when proc is
not compiled in.
I.e. I see no hope for salvaging the selinux_proc_get_sid call
in selinux_sysctl so I'm removing it.
Signed-off-by: Eric W. Biederman <[email protected]>
---
security/selinux/hooks.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7b38372..3a36057 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1438,12 +1438,8 @@ static int selinux_sysctl(ctl_table *table, int op)
tsec = current->security;
- rc = selinux_proc_get_sid(table->de, (op == 001) ?
- SECCLASS_DIR : SECCLASS_FILE, &tsid);
- if (rc) {
- /* Default to the well-defined sysctl SID. */
- tsid = SECINITSID_SYSCTL;
- }
+ /* Use the well-defined sysctl SID. */
+ tsid = SECINITSID_SYSCTL;
/* The op values are "defined" in sysctl.c, thereby creating
* a bad coupling between this module and sysctl.c */
--
1.4.4.1.g278f
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
