[RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

This patch series adds support of procfs mount options and adds
mount options to restrict /proc/<pid>/ directories to owners and
/proc/<pid>/net/* to root.  Additional group may be defined via
gid=, and this group will be privileged to study others /proc/<pid>/
and networking information.

Similar features are implemented for old kernels in -ow patches (for
Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
are implemented as configure options, not cofigurable in runtime, with
changes of gid of /proc/<pid>/, and without backward-compatible
/proc/<pid>/net/* handling.


The first patch introduces mount option parsing without any new options.
The second patch adds options of /proc/<pid>/ restrictions.
The third patch makes net_create() globally visible.
The fourth patch adds options of /proc/<pid>/net/ restrictions.
The fifth patch adds documentations for options above.

Vasiliy Kulikov (5):
  procfs: parse mount options
  procfs: add hidepid= and gid= mount options
  net: restore net_create and make it globally visible
  procfs: Add hidenet/nohidenet procfs mount options.
  procfs: add documentation for procfs mount options

 Documentation/filesystems/proc.txt |   51 ++++++++++++++++++++++
 fs/proc/base.c                     |   62 ++++++++++++++++++++++++++-
 fs/proc/inode.c                    |   20 +++++++++
 fs/proc/internal.h                 |    1 +
 fs/proc/proc_net.c                 |   26 +++++++++++
 fs/proc/root.c                     |   83 +++++++++++++++++++++++++++++++++++-
 include/linux/pid_namespace.h      |    3 +
 include/net/net_namespace.h        |    2 +
 net/core/net_namespace.c           |   12 +++--
 9 files changed, 253 insertions(+), 7 deletions(-)

[kernel-hardening] [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

This patch series adds support of procfs mount options and adds
mount options to restrict /proc/<pid>/ directories to owners and
/proc/<pid>/net/* to root.  Additional group may be defined via
gid=, and this group will be privileged to study others /proc/<pid>/
and networking information.

Similar features are implemented for old kernels in -ow patches (for
Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
are implemented as configure options, not cofigurable in runtime, with
changes of gid of /proc/<pid>/, and without backward-compatible
/proc/<pid>/net/* handling.


The first patch introduces mount option parsing without any new options.
The second patch adds options of /proc/<pid>/ restrictions.
The third patch makes net_create() globally visible.
The fourth patch adds options of /proc/<pid>/net/ restrictions.
The fifth patch adds documentations for options above.

Vasiliy Kulikov (5):
  procfs: parse mount options
  procfs: add hidepid= and gid= mount options
  net: restore net_create and make it globally visible
  procfs: Add hidenet/nohidenet procfs mount options.
  procfs: add documentation for procfs mount options

 Documentation/filesystems/proc.txt |   51 ++++++++++++++++++++++
 fs/proc/base.c                     |   62 ++++++++++++++++++++++++++-
 fs/proc/inode.c                    |   20 +++++++++
 fs/proc/internal.h                 |    1 +
 fs/proc/proc_net.c                 |   26 +++++++++++
 fs/proc/root.c                     |   83 +++++++++++++++++++++++++++++++++++-
 include/linux/pid_namespace.h      |    3 +
 include/net/net_namespace.h        |    2 +
 net/core/net_namespace.c           |   12 +++--
 9 files changed, 253 insertions(+), 7 deletions(-)

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Arnd Bergmann]

On Wednesday 15 June 2011, Vasiliy Kulikov wrote:
> 
> This patch series adds support of procfs mount options and adds
> mount options to restrict /proc/<pid>/ directories to owners and
> /proc/<pid>/net/* to root.  Additional group may be defined via
> gid=, and this group will be privileged to study others /proc/<pid>/
> and networking information.
> 
> Similar features are implemented for old kernels in -ow patches (for
> Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
> are implemented as configure options, not cofigurable in runtime, with
> changes of gid of /proc/<pid>/, and without backward-compatible
> /proc/<pid>/net/* handling.

The patches all look good to me implementation-wise.

I have no opinion on whether it's a good idea to include the feature or not.

	Arnd

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Arnd Bergmann]

On Wednesday 15 June 2011, Vasiliy Kulikov wrote:
> 
> This patch series adds support of procfs mount options and adds
> mount options to restrict /proc/<pid>/ directories to owners and
> /proc/<pid>/net/* to root.  Additional group may be defined via
> gid=, and this group will be privileged to study others /proc/<pid>/
> and networking information.
> 
> Similar features are implemented for old kernels in -ow patches (for
> Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
> are implemented as configure options, not cofigurable in runtime, with
> changes of gid of /proc/<pid>/, and without backward-compatible
> /proc/<pid>/net/* handling.

The patches all look good to me implementation-wise.

I have no opinion on whether it's a good idea to include the feature or not.

	Arnd

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

Hi Arnd,

On Thu, Jun 16, 2011 at 10:50 +0200, Arnd Bergmann wrote:
> The patches all look good to me implementation-wise.

Thanks for the review!

> I have no opinion on whether it's a good idea to include the feature or not.

Why not?  Have you some specific complains where it can be perhaps too
strong/insufficient/non-configurable?

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

Hi Arnd,

On Thu, Jun 16, 2011 at 10:50 +0200, Arnd Bergmann wrote:
> The patches all look good to me implementation-wise.

Thanks for the review!

> I have no opinion on whether it's a good idea to include the feature or not.

Why not?  Have you some specific complains where it can be perhaps too
strong/insufficient/non-configurable?

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Arnd Bergmann]

On Thursday 16 June 2011, Vasiliy Kulikov wrote:
> > I have no opinion on whether it's a good idea to include the feature or not.
> 
> Why not?  Have you some specific complains where it can be perhaps too
> strong/insufficient/non-configurable?

No, not at all. I just haven't had the need for this myself, and I'm not
enough of a security person to judge whether the vulnerability addressed
by the patch is a relevant one. E.g. if all the sensitive information
you are hiding in procfs is still available through netlink, your patch
is pointless. Similarly if there is no recorded case of an attack that
relies on any of the information in procfs.

	Arnd

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Arnd Bergmann]

On Thursday 16 June 2011, Vasiliy Kulikov wrote:
> > I have no opinion on whether it's a good idea to include the feature or not.
> 
> Why not?  Have you some specific complains where it can be perhaps too
> strong/insufficient/non-configurable?

No, not at all. I just haven't had the need for this myself, and I'm not
enough of a security person to judge whether the vulnerability addressed
by the patch is a relevant one. E.g. if all the sensitive information
you are hiding in procfs is still available through netlink, your patch
is pointless. Similarly if there is no recorded case of an attack that
relies on any of the information in procfs.

	Arnd

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

Arnd,

On Thu, Jun 16, 2011 at 13:40 +0200, Arnd Bergmann wrote:
> E.g. if all the sensitive information
> you are hiding in procfs is still available through netlink, your patch
> is pointless.

Ah, I've complitely missed this piece of a puzzle! :( With procfs, proc
connector and taskstats (probably, something else) should be restricted
too.

Thank you very much for this notice!

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

Arnd,

On Thu, Jun 16, 2011 at 13:40 +0200, Arnd Bergmann wrote:
> E.g. if all the sensitive information
> you are hiding in procfs is still available through netlink, your patch
> is pointless.

Ah, I've complitely missed this piece of a puzzle! :( With procfs, proc
connector and taskstats (probably, something else) should be restricted
too.

Thank you very much for this notice!

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[richard -rw- weinberger]

On Thu, Jun 16, 2011 at 12:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 16 June 2011, Vasiliy Kulikov wrote:
>> > I have no opinion on whether it's a good idea to include the feature or not.
>>
>> Why not?  Have you some specific complains where it can be perhaps too
>> strong/insufficient/non-configurable?
>
> No, not at all. I just haven't had the need for this myself, and I'm not
> enough of a security person to judge whether the vulnerability addressed
> by the patch is a relevant one. E.g. if all the sensitive information
> you are hiding in procfs is still available through netlink, your patch
> is pointless. Similarly if there is no recorded case of an attack that
> relies on any of the information in procfs.
>

Is this interface somewhere documented?
IOW how is it possible to get all processes via netlink?

-- 
Thanks,
//richard

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[richard -rw- weinberger]

On Thu, Jun 16, 2011 at 12:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 16 June 2011, Vasiliy Kulikov wrote:
>> > I have no opinion on whether it's a good idea to include the feature or not.
>>
>> Why not?  Have you some specific complains where it can be perhaps too
>> strong/insufficient/non-configurable?
>
> No, not at all. I just haven't had the need for this myself, and I'm not
> enough of a security person to judge whether the vulnerability addressed
> by the patch is a relevant one. E.g. if all the sensitive information
> you are hiding in procfs is still available through netlink, your patch
> is pointless. Similarly if there is no recorded case of an attack that
> relies on any of the information in procfs.
>

Is this interface somewhere documented?
IOW how is it possible to get all processes via netlink?

-- 
Thanks,
//richard

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Andrew Morton]

Plese cc Alexey on procfs things.

On Wed, 15 Jun 2011 22:51:35 +0400
Vasiliy Kulikov <segoon@openwall.com> wrote:

> This patch series adds support of procfs mount options and adds
> mount options to restrict /proc/<pid>/ directories to owners and
> /proc/<pid>/net/* to root.  Additional group may be defined via
> gid=, and this group will be privileged to study others /proc/<pid>/
> and networking information.
> 
> Similar features are implemented for old kernels in -ow patches (for
> Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
> are implemented as configure options, not cofigurable in runtime, with
> changes of gid of /proc/<pid>/, and without backward-compatible
> /proc/<pid>/net/* handling.

This all seems highly specific to one particular set of requirements. 
We have one set of access permission rules and then dive into procfs
and hard-wire those rules into the implementation?  What happens if
someone else has a similar but slightly different set of requirements? 
More kernel patches?

IOW is there some more general way of doing all this?  <handwaving>Like
better permissions/chmod support in procfs and an inherited-across-fork
per-process procfs permissions mask.</handwaving>


Does all this code support `mount -o remount' as expected?

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Andrew Morton]

Plese cc Alexey on procfs things.

On Wed, 15 Jun 2011 22:51:35 +0400
Vasiliy Kulikov <segoon@openwall.com> wrote:

> This patch series adds support of procfs mount options and adds
> mount options to restrict /proc/<pid>/ directories to owners and
> /proc/<pid>/net/* to root.  Additional group may be defined via
> gid=, and this group will be privileged to study others /proc/<pid>/
> and networking information.
> 
> Similar features are implemented for old kernels in -ow patches (for
> Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
> are implemented as configure options, not cofigurable in runtime, with
> changes of gid of /proc/<pid>/, and without backward-compatible
> /proc/<pid>/net/* handling.

This all seems highly specific to one particular set of requirements. 
We have one set of access permission rules and then dive into procfs
and hard-wire those rules into the implementation?  What happens if
someone else has a similar but slightly different set of requirements? 
More kernel patches?

IOW is there some more general way of doing all this?  <handwaving>Like
better permissions/chmod support in procfs and an inherited-across-fork
per-process procfs permissions mask.</handwaving>


Does all this code support `mount -o remount' as expected?

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

Hi,

First of all, to make it clear, this specific patch is not proposed
anymore because it doesn't restrict taskstats which can be used to
gather similar information.  The patch working with taskstats (and
without hidepid=2) was not yet posted on LKML, but is available here:

http://www.openwall.com/lists/kernel-hardening/2011/06/19/3

On Tue, Jun 21, 2011 at 15:31 -0700, Andrew Morton wrote:
> > This patch series adds support of procfs mount options and adds
> > mount options to restrict /proc/<pid>/ directories to owners and
> > /proc/<pid>/net/* to root.  Additional group may be defined via
> > gid=, and this group will be privileged to study others /proc/<pid>/
> > and networking information.
> > 
> > Similar features are implemented for old kernels in -ow patches (for
> > Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
> > are implemented as configure options, not cofigurable in runtime, with
> > changes of gid of /proc/<pid>/, and without backward-compatible
> > /proc/<pid>/net/* handling.
> 
> This all seems highly specific to one particular set of requirements. 

Yes, I admit this.  The problem with procfs is that it's possible to
chmod/chown some procfs files, but not /proc/PID/*.  Even if make it
possible to chmod/chown them (and introducing an inodes revalidation on
execve() setuid and similar binaries) it is still racy - new processes
would have /proc/PID/ and some files inside with perms=0555.  So, for
more generic mechanism something like umask is needed.  The patch in
question implements 2 border cases:

1) relaxed.  umask=0555.

2) restricted.  umask=0550 (with tricky gid) and files are still not
chmod'able.


More generic solution (I'm not suggesting it, but merely discussing)
would use some user-supplied set of files to restrict access to (or,
better, the set of allowed files because white list is almost always
better than black list).  Maybe this one:

    mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc

And without pid_allow it would behave like pid_allow=*.  "pid_allow=."
would deny access to the whole /proc/PID.

This would be a bit inconsistent with current permissions because e.g.
if use pid_allow=environ then environ file would not be accessible
because of posix permissions.  Hierarchical mode (pid_allow=fd/1) is not
allowed too.


But it wouldn't work with taskstats.  It needs its own set of allowed
fields or field sets like delayacct,csw,bacct,xacct.


> IOW is there some more general way of doing all this?  <handwaving>Like
> better permissions/chmod support in procfs and an inherited-across-fork
> per-process procfs permissions mask.</handwaving>

I don't know such way, but it would ease procfs logic.


> Does all this code support `mount -o remount' as expected?

Yes.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

Hi,

First of all, to make it clear, this specific patch is not proposed
anymore because it doesn't restrict taskstats which can be used to
gather similar information.  The patch working with taskstats (and
without hidepid=2) was not yet posted on LKML, but is available here:

http://www.openwall.com/lists/kernel-hardening/2011/06/19/3

On Tue, Jun 21, 2011 at 15:31 -0700, Andrew Morton wrote:
> > This patch series adds support of procfs mount options and adds
> > mount options to restrict /proc/<pid>/ directories to owners and
> > /proc/<pid>/net/* to root.  Additional group may be defined via
> > gid=, and this group will be privileged to study others /proc/<pid>/
> > and networking information.
> > 
> > Similar features are implemented for old kernels in -ow patches (for
> > Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them
> > are implemented as configure options, not cofigurable in runtime, with
> > changes of gid of /proc/<pid>/, and without backward-compatible
> > /proc/<pid>/net/* handling.
> 
> This all seems highly specific to one particular set of requirements. 

Yes, I admit this.  The problem with procfs is that it's possible to
chmod/chown some procfs files, but not /proc/PID/*.  Even if make it
possible to chmod/chown them (and introducing an inodes revalidation on
execve() setuid and similar binaries) it is still racy - new processes
would have /proc/PID/ and some files inside with perms=0555.  So, for
more generic mechanism something like umask is needed.  The patch in
question implements 2 border cases:

1) relaxed.  umask=0555.

2) restricted.  umask=0550 (with tricky gid) and files are still not
chmod'able.


More generic solution (I'm not suggesting it, but merely discussing)
would use some user-supplied set of files to restrict access to (or,
better, the set of allowed files because white list is almost always
better than black list).  Maybe this one:

    mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc

And without pid_allow it would behave like pid_allow=*.  "pid_allow=."
would deny access to the whole /proc/PID.

This would be a bit inconsistent with current permissions because e.g.
if use pid_allow=environ then environ file would not be accessible
because of posix permissions.  Hierarchical mode (pid_allow=fd/1) is not
allowed too.


But it wouldn't work with taskstats.  It needs its own set of allowed
fields or field sets like delayacct,csw,bacct,xacct.


> IOW is there some more general way of doing all this?  <handwaving>Like
> better permissions/chmod support in procfs and an inherited-across-fork
> per-process procfs permissions mask.</handwaving>

I don't know such way, but it would ease procfs logic.


> Does all this code support `mount -o remount' as expected?

Yes.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

On Wed, Jun 22, 2011 at 10:45 +0400, Vasiliy Kulikov wrote:
> More generic solution (I'm not suggesting it, but merely discussing)
> would use some user-supplied set of files to restrict access to (or,
> better, the set of allowed files because white list is almost always
> better than black list).  Maybe this one:
> 
>     mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc
> 
> And without pid_allow it would behave like pid_allow=*.

>  "pid_allow=."
> would deny access to the whole /proc/PID.

I mean "pid_allow=", of course.

> This would be a bit inconsistent with current permissions because e.g.
> if use pid_allow=environ then environ file would not be accessible
> because of posix permissions.  Hierarchical mode (pid_allow=fd/1) is not
> allowed too.

For hierarchical mode: attr_allowed, tgid_allowed, tid_allowed.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

On Wed, Jun 22, 2011 at 10:45 +0400, Vasiliy Kulikov wrote:
> More generic solution (I'm not suggesting it, but merely discussing)
> would use some user-supplied set of files to restrict access to (or,
> better, the set of allowed files because white list is almost always
> better than black list).  Maybe this one:
> 
>     mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc
> 
> And without pid_allow it would behave like pid_allow=*.

>  "pid_allow=."
> would deny access to the whole /proc/PID.

I mean "pid_allow=", of course.

> This would be a bit inconsistent with current permissions because e.g.
> if use pid_allow=environ then environ file would not be accessible
> because of posix permissions.  Hierarchical mode (pid_allow=fd/1) is not
> allowed too.

For hierarchical mode: attr_allowed, tgid_allowed, tid_allowed.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

On Wed, Jun 22, 2011 at 10:45 +0400, Vasiliy Kulikov wrote:
> > This all seems highly specific to one particular set of requirements. 
> 
> Yes, I admit this.  The problem with procfs is that it's possible to
> chmod/chown some procfs files, but not /proc/PID/*.  Even if make it
> possible to chmod/chown them (and introducing an inodes revalidation on
> execve() setuid and similar binaries) it is still racy - new processes
> would have /proc/PID/ and some files inside with perms=0555.  So, for
> more generic mechanism something like umask is needed.  The patch in
> question implements 2 border cases:
> 
> 1) relaxed.  umask=0555.
> 
> 2) restricted.  umask=0550 (with tricky gid) and files are still not
> chmod'able.
> 
> 
> More generic solution (I'm not suggesting it, but merely discussing)
> would use some user-supplied set of files to restrict access to (or,
> better, the set of allowed files because white list is almost always
> better than black list).  Maybe this one:
> 
>     mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc

Does this scheme make sense?  Should I rensend the patch with these
architecture?

pid_allow=, tid_allow=, attr_allow= and watch_gid= or smth like that.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Vasiliy Kulikov]

On Wed, Jun 22, 2011 at 10:45 +0400, Vasiliy Kulikov wrote:
> > This all seems highly specific to one particular set of requirements. 
> 
> Yes, I admit this.  The problem with procfs is that it's possible to
> chmod/chown some procfs files, but not /proc/PID/*.  Even if make it
> possible to chmod/chown them (and introducing an inodes revalidation on
> execve() setuid and similar binaries) it is still racy - new processes
> would have /proc/PID/ and some files inside with perms=0555.  So, for
> more generic mechanism something like umask is needed.  The patch in
> question implements 2 border cases:
> 
> 1) relaxed.  umask=0555.
> 
> 2) restricted.  umask=0550 (with tricky gid) and files are still not
> chmod'able.
> 
> 
> More generic solution (I'm not suggesting it, but merely discussing)
> would use some user-supplied set of files to restrict access to (or,
> better, the set of allowed files because white list is almost always
> better than black list).  Maybe this one:
> 
>     mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc

Does this scheme make sense?  Should I rensend the patch with these
architecture?

pid_allow=, tid_allow=, attr_allow= and watch_gid= or smth like that.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Alexey Dobriyan]

On Wed, Jun 29, 2011 at 10:16 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
>>     mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc
>
> Does this scheme make sense?  Should I rensend the patch with these
> architecture?
>
> pid_allow=, tid_allow=, attr_allow= and watch_gid= or smth like that.

Wildcards are scary, can we please not do them from the beginning.

[kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options

[Alexey Dobriyan]

On Wed, Jun 29, 2011 at 10:16 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
>>     mount -t proc -o "pid_allow=exe,status,comm,oom_*" proc /proc
>
> Does this scheme make sense?  Should I rensend the patch with these
> architecture?
>
> pid_allow=, tid_allow=, attr_allow= and watch_gid= or smth like that.

Wildcards are scary, can we please not do them from the beginning.