lkml.org 
[lkml]   [2007]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] sysctl selinux: Don't look at table->de
    Date
    Stephen Smalley <sds@tycho.nsa.gov> writes:

    > On Sun, 2007-01-28 at 12:21 -0700, Eric W. Biederman wrote:
    >> 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 <ebiederm@xmission.com>
    >> ---
    >> 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 */
    >
    > NAK. Mapping all sysctls to a single security label prevents any kind
    > of fine-grained security on sysctls, and current policies already make
    > use of the current distinctions to limit access to particular sets of
    > sysctls to particular processes. As is, I'd expect breakage of current
    > systems running SELinux from this patch, because (confined) processes
    > that formerly only required access to specific sysctl labels will
    > suddenly run into denials on the generic fallback label.

    Reasonable. There is the issue that your code already had this code
    path for when /proc was compiled out.

    > If the ctl_table supplied more information about the functional purpose
    > and the security sensitivity of the sysctl, then we could leverage that
    > information instead, as long as we can at least derive the current
    > labelings from that information for compatibility.

    What do information do you need to do need? Do you need extra fields in sysctl?
    I am more than willing to help but I am not familiar enough with selinux
    to do a reasonable job on my own.

    Eric
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-01-29 18:47    [W:0.027 / U:1.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site