public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "Andrew G. Morgan" <morgan@kernel.org>
Cc: Ismail D??nmez <ismail@pardus.org.tr>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Security Modules List 
	<linux-security-module@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	"Serge E. Hallyn" <serue@us.ibm.com>
Subject: Re: [PATCH] per-process securebits
Date: Mon, 4 Feb 2008 10:45:24 -0600	[thread overview]
Message-ID: <20080204164524.GC20130@sergelap.ibm.com> (raw)
In-Reply-To: <47A6661D.7020305@kernel.org>

Quoting Andrew G. Morgan (morgan@kernel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ismail D??nmez wrote:
> | What I meant to ask was what does "per-process securebits" brings as
> extra.
>
> It allows you to create a legacy free process tree. For example, a
> chroot, or container (which Serge can obviously explain in more detail),

(Just to give my thoughts on securebits and containers)

A container is a set of processes which has its own private namespaces
for all or most resources - for instance it sees only processes in its
own pid namespace, and its first process, which is sees as pid 1, is
known as some other pid, maybe 3459, to the rest of the system.

We tend to talk about 'system containers' versus 'application
containers'.  A system container would be like a vserver or openvz
instance, something which looks like a separate machine.  I was
going to say I don't imagine per-process securebits being useful
there, but actually since a system container doesn't need to do any
hardware setup it actually might be a much easier start for a full
SECURE_NOROOT distro than a real machine.  Heck, on a real machine init
and a few legacy deamons could run in the init namespace, while users
log in and apache etc run in a SECURE_NOROOT container.

But I especially like the thought of for instance postfix running in a
carefully crafted application container (with its own virtual network
card and limited file tree and no visibility of other processes) with
SECURE_NOROOT on.

-serge

> environment in which root has no privilege at all. One in which
> privilege comes only from filesystem capabilities.
>
> | FWIW in Pardus 2008 we'll enable Posix file capabilities by default so
> people
> | could "harden" their setups.

Cool.  Be good to see how that goes.  I'm curious about what conceptual
hurdles there might be for sysadmins configuring libpam to exploit
fI+pI.

thanks,
-serge

>
> Cheers
>
> Andrew
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFHpmYd+bHCR3gb8jsRAlDHAJ9RvFRieU2eUPJUHh7K84NMLmytTQCgupfS
> KxdoXz400AeMWJiaikGH9U8=
> =yx8I
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2008-02-04 16:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-01  8:11 [PATCH] per-process securebits Andrew G. Morgan
2008-02-01  8:28 ` Andrew Morton
2008-02-01  9:07   ` James Morris
2008-02-04 18:17     ` Pavel Machek
2008-02-04 22:00       ` Andrew Morton
2008-02-03  6:01   ` Andrew G. Morgan
2008-02-03  6:18     ` Andrew Morton
2008-02-03  6:25       ` Ismail Dönmez
2008-02-04  0:49         ` Andrew G. Morgan
2008-02-04  0:54           ` Ismail Dönmez
2008-02-04  1:10             ` Andrew G. Morgan
2008-02-04 16:45               ` Serge E. Hallyn [this message]
2008-02-05  1:15                 ` Ismail Dönmez
2008-02-01 20:15 ` serge
2008-02-03  6:11   ` Andrew G. Morgan
2008-02-05 18:46 ` Serge E. Hallyn

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=20080204164524.GC20130@sergelap.ibm.com \
    --to=serue@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ismail@pardus.org.tr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    /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