[redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches)

James Antill jantill at redhat.com
Thu Nov 9 15:40:50 UTC 2006


On Thu, 2006-11-09 at 10:07 -0500, Stephen Smalley wrote:
> On Wed, 2006-11-08 at 18:47 -0500, James Antill wrote:
> >  Attached is the latest cron patch.
> 
> diff -rup vixie-cron-4.1-orig/security.c vixie-cron-4.1/security.c
> --- vixie-cron-4.1-orig/security.c	2006-11-02 22:28:04.000000000 -0500
> +++ vixie-cron-4.1/security.c	2006-11-08 17:35:27.000000000 -0500
> +static int 
> +cron_authorize_range
> +( 
> +	security_context_t scontext,
> +	security_context_t ucontext
> +)	
> +{
> +#ifdef WITH_SELINUX
> +	struct av_decision avd;
> +	int retval;
> +        unsigned int bit = CONTEXT__CONTAINS;
> +	/*
> +	 * Since crontab files are not directly executed,
> +	 * so crond must ensure that any user specified range
> +	 * is allowed by the default users range.  It performs
> +         * an entrypoint permission check for this purpose.
> +	 */
> 
> Still not accurate.  This check is quite different in purpose and
> rationale than the entrypoint check; it has nothing to do with the fact
> that crontab files are not directly executed.  It is just a check of
> whether the user-specified level falls within the seusers-specified
> range for that Linux user.

 Ok. I've changed the comment again.

> +static int cron_change_selinux_range( user *u,
> +                                      security_context_t ucontext )
> +{
> +	if ( is_selinux_enabled() <= 0 )
> +		return 0;
> +
> +	if ( u->scontext == 0L )
> +	{
> +		if (security_getenforce() > 0) 
> +		{
> +			log_it( u->name, getpid(), 
> +				"NULL security context for user", 
> +				""
> +			      );
> +			return -1;
> +		}else
> +		{
> +			log_it( u->name, getpid(), 
> +				"NULL security context for user, "
> +				"but SELinux in permissive mode, continuing",
> +				""
> +				);
> +			return 0;
> +		}
> 
> Another case where I don't understand why enforcing/permissive makes any
> difference.

 Because without enforcing mode we just ignore the problem and continue,
with it we error out. I think this is more of a theoretical assert type
problem anyway, but still.

> Still refers to SELINUX_ROLE_TYPE in the log message.

 Fixed.

> +	if ( setexeccon(ucontext) < 0 ) 
> +	{
> +		if (security_getenforce() > 0) 
> +		{
> +			syslog(LOG_ERR,
> +			       "CRON (%s) ERROR:"
> +			       "Could not set exec context to %s for user", 
> +			       u->name, (char*)ucontext
> +			      );
> +
> +			return -1;
> +		}
> 
> Likely want to log something in the else case too so you don't just
> silently proceed under crond's own context.

 Done.

-- 
James Antill - <james.antill at redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vixie-cron-4.1-_60-SELinux-contains-range.patch
Type: text/x-patch
Size: 7696 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20061109/c8f46b2c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20061109/c8f46b2c/attachment.sig>


More information about the redhat-lspp mailing list