public inbox for kernel-hardening@lists.openwall.com
 help / color / mirror / Atom feed
From: Solar Designer <solar@openwall.com>
To: kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] procfs mount options
Date: Sun, 5 Jun 2011 23:40:52 +0400	[thread overview]
Message-ID: <20110605194052.GA9370@openwall.com> (raw)
In-Reply-To: <20110605191747.GA6174@albatros>

On Sun, Jun 05, 2011 at 11:17:47PM +0400, Vasiliy Kulikov wrote:
> On Sun, Jun 05, 2011 at 00:59 +0400, Solar Designer wrote:
> > Here's a related thought: if these mount options happen to affect all
> > instances of the filesystem (in the same container), maybe they should
> > be sysctl's instead?
> 
> AFAIR, only net namespaces have their own sysctl sets.  Other sysctls
> are global.  So, implementing pid_namespace-specific sysctl would be a
> bit weird (according to current policies).

Here's what we have immediate need for, in practice:

We need to be able to mount /proc with different permission settings in
different OpenVZ containers (perhaps running different distros, which
have their different defaults - e.g., Owl will use the restricted proc
options by default, but other distros mostly won't).

Since recent versions of OpenVZ build upon the namespaces code that has
been upstream'ed, I guess this will rely on upstream's namespaces code
(once we move to RHEL6'ish OpenVZ kernels and beyond), correct?

Now, leaving sysctl's aside and speaking of mount options only for now,
what happens when a container mounts /proc with umask=007, but then
another container mounts /proc without that option or with umask=0?
Does the first container retain its restricted perms, including for
newly appearing entries under its /proc?  If so, where is this different
setting stored?  Is it per mount (preferable)?  Is it per pid namespace
(OK)?  Or per net namespace (weird)?

Thanks,

Alexander

  reply	other threads:[~2011-06-05 19:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110603191153.GB514@openwall.com>
2011-06-04  5:47 ` [kernel-hardening] Re: procfs mount options Vasiliy Kulikov
2011-06-04 13:20   ` [kernel-hardening] " Solar Designer
2011-06-04 20:09     ` Vasiliy Kulikov
2011-06-04 20:59       ` Solar Designer
2011-06-05 18:24         ` [kernel-hardening] [RFC v1] " Vasiliy Kulikov
2011-06-05 19:26           ` Solar Designer
2011-06-05 19:47             ` Vasiliy Kulikov
2011-06-05 20:10               ` Solar Designer
2011-06-06 18:08                 ` Vasiliy Kulikov
2011-06-06 18:33                   ` Solar Designer
2011-06-08 17:23                     ` [kernel-hardening] [RFC v2] " Vasiliy Kulikov
2011-06-08 17:43                       ` Vasiliy Kulikov
2011-06-12  2:39                       ` Solar Designer
2011-07-24 18:55                         ` Vasiliy Kulikov
     [not found]                         ` <20110724185036.GC3510@albatros>
2011-07-26 14:50                           ` Vasiliy Kulikov
2011-07-29 17:47                             ` [kernel-hardening] procfs {tid,tgid,attr}_allowed " Vasiliy Kulikov
2011-08-04 11:23                               ` [kernel-hardening] " Vasiliy Kulikov
2011-08-10 10:02                                 ` Vasiliy Kulikov
2011-08-10 11:22                                   ` [kernel-hardening] " Solar Designer
2011-08-10 11:25                                 ` Solar Designer
2011-08-10 12:04                                   ` Vasiliy Kulikov
2011-08-10 13:34                                     ` Solar Designer
2011-08-12 18:14                                       ` Simon Marechal
2011-06-06 19:20                 ` [kernel-hardening] [RFC v1] procfs " Vasiliy Kulikov
2011-06-05 19:17         ` [kernel-hardening] " Vasiliy Kulikov
2011-06-05 19:40           ` Solar Designer [this message]
2011-06-05 19:53             ` Vasiliy Kulikov
2011-06-05 18:36 ` [kernel-hardening] Re: [owl-dev] " Vasiliy Kulikov
2011-06-05 18:47   ` [kernel-hardening] " Solar Designer

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=20110605194052.GA9370@openwall.com \
    --to=solar@openwall.com \
    --cc=kernel-hardening@lists.openwall.com \
    /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