mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: David Madore <david.madore@ens.fr>
Cc: Linux Kernel mailing-list <linux-kernel@vger.kernel.org>,
	LSM mailing-list <linux-security-module@vger.kernel.org>,
	Louis Kruger <lpkruger@cs.wisc.edu>,
	"Bill O'Donnell" <billodo@sgi.com>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] security: add a "cuppabilities" security module (preliminary version)
Date: Sun, 17 Sep 2006 15:04:58 +0200	[thread overview]
Message-ID: <20060917130458.GL2741@elf.ucw.cz> (raw)
In-Reply-To: <20060916232540.GA15092@clipper.ens.fr>

Hi!

> This patch adds a Linux Security Module called "cuppabilities", which
> allows for an easy creation of underprivileged processes:
> 
>  * add a "cuppabilities" field to the task structure, and two prctl()
>    calls (PR_GET_CUPS and PR_ADD_CUPS) which manipulate it,
> 
>  * add a LSM which forbids certain operations when various bits are
>    set in this field (otherwise it also calls commoncap operations
>    secondarily).
> 
> So far this is only a preliminary demonstration of concept, so only
> very uninteresting cuppabilities are included: CUP_FORK, some variants
> on CUP_EXEC (including CUP_EXEC_SXID) and CUP_PTRACE.

Basically looks good to me.

> 		*** IMPORTANT NOTE ***
> 
> 	This patch IS NOT related (nor compatible) with the one posted
> 	a few days ago on this list under the name "new capabilities
> 	patch".  The latter treated underprivileged processes as
> 	lacking some capabilities.  It has been abandoned due to heavy
> 	criticism on LKML.  *This* patch adds a completely different
> 	field, "cuppabilities", and treats cuppabilities in a simpler
> 	fashion than capabilities (only one set per task rather than
> 	permitted/effective/inheritable, and just a simple prctl() to
> 	add cups - for example, a simple prctl(PR_ADD_CUPS,
> 	(1<<CUP_EXEC_SXID)) forbids suid/sgid exec from then on).
> 
> 	This patch should not break (or indeed change!) anything for
> 	those who don't activate support for cuppabilities.
> 
> 	Comments are appreciated on whether this is the right way to
> 	proceed, especially from those who criticized my earlier
> 	(aforementioned) capabilities patch.

This should go to Documentation/, somewhere.

Why the cuppability name?

> +/*
> + * This is <linux/cuppability.h>
> + *
> + * David A. Madore <david.madore@ens.fr>
> + */ 
> +
> +#ifndef _LINUX_CUPPABILITY_H
> +#define _LINUX_CUPPABILITY_H
> +
> +#define CUP_NONE 0UL
> +#define CUP_ALL 0xffffffUL
> +
> +#define CUP_TO_MASK(x) (1UL << (x))
> +#define cup_raise(c, flag)   ((c) |=  CAP_TO_MASK(flag))
> +#define cup_lower(c, flag)   ((c) &= ~CAP_TO_MASK(flag))
> +#define cup_raised(c, flag)  ((c) & CAP_TO_MASK(flag))
> +
> +#define CUP_FORK		0 /* Forbid fork() */

This is reverted from normal meaning, now?

> @@ -2055,6 +2056,12 @@ asmlinkage long sys_prctl(int option, un
>  		case PR_SET_ENDIAN:
>  			error = SET_ENDIAN(current, arg2);
>  			break;
> +		case PR_GET_CUPS:
> +			error = current->cuppabilities;
> +			break;

Yep, it seems so.

> +#if defined(CONFIG_SECURITY_CUPPABILITY_MODULE)
> +#define MY_NAME THIS_MODULE->name
> +#else
> +#define MY_NAME "cuppability"
> +#endif

Now this is what I'd call a hack...

> +static int cup_ptrace (struct task_struct *parent, struct task_struct *child)
> +{
> +	if (cup_raised (current->cuppabilities, CUP_PTRACE))
                      ~
		      \- you should avoid this space.

> +static void cup_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
> +{
> +	if (bprm->is_suid || bprm->is_sgid) {
> +		current->cuppabilities = CUP_NONE;
> +	}

Hmm, meaning is really inverted CUP_NONE means "forbid nothing".. not
forbid everything... right?

> +MODULE_DESCRIPTION("Root Plug sample LSM module, written for Linux Journal article");

Hmm, probably not...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

      reply	other threads:[~2006-09-17 13:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-16 23:25 David Madore
2006-09-17 13:04 ` Pavel Machek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060917130458.GL2741@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=billodo@sgi.com \
    --cc=casey@schaufler-ca.com \
    --cc=david.madore@ens.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lpkruger@cs.wisc.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome