Re: [PATCH] sysctl selinux: Don't look at table->de

[Stephen Smalley <sds@tycho.nsa.gov>]

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.

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.

-- 
Stephen Smalley
National Security Agency