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
prev parent 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