From: "Serge E. Hallyn" <serge@hallyn.com>
To: Djalal Harouni <tixxdz@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LSM List <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Dongsu Park <dpark@posteo.net>,
Casey Schaufler <casey@schaufler-ca.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <paul@paul-moore.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
belakhdar abdeldjalil <zendyani@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Thu, 4 May 2017 09:58:33 -0500 [thread overview]
Message-ID: <20170504145832.GA28002@mail.hallyn.com> (raw)
In-Reply-To: <CAEiveUf4p1A1fggwibN+kJW7ruasQCmzr6=GSpTZXoyjJuz00Q@mail.gmail.com>
On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote:
> On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
> > On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> [...]
> >>
> >> My point is that all of these need some way to handle configuration
> >> and inheritance, and I don't think that a bunch of per-task prctls is
> >> the right way. As just an example, saying that interactive users can
> >> autoload modules but other users can't, or that certain systemd
> >> services can, etc, might be nice. Linus already complained that he
> >> (i.e. user "torvalds" or whatever) should be able to profile the
> >> kernel but that other uids should not be able to.
> >
> > Neat, maybe this could already be achieved with this interface and
> > systemd-logind, "ModulesAutoloadUsers=andy" in logind.conf where
> > "andy" is the only logged-in user able to trigger and autoload kernel
> > modules. However maybe we should not restrict too much other bits or
> > functionality of the other users, please let me will follow up later
> > on it.
> >
> >> I personally like my implicit_rights idea, and it might be interesting
> >> to prototype it.
> >
>
> Andy following on the idea of per user settings, I'm curious did you
> manage to make some advance on how to store the user settings ? the
> user database format is old and not extensible, there was cgmanager or
(v2 is under very very early consideration, would love to stay in the loop
as this is considered)
> other libcgroup but for resources, and no simple thing for such
> restrictions example: "RestrictLinuxModules=user" that will prevent
> such users from making/loading extra Linux features/modules that are
> not already available...
>
> Thanks!
>
> --
> tixxdz
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Djalal Harouni <tixxdz@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LSM List <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Dongsu Park <dpark@posteo.net>,
Casey Schaufler <casey@schaufler-ca.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <paul@paul-moore.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Ingo Molnar <mingo@ker>
Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Thu, 4 May 2017 09:58:33 -0500 [thread overview]
Message-ID: <20170504145832.GA28002@mail.hallyn.com> (raw)
In-Reply-To: <CAEiveUf4p1A1fggwibN+kJW7ruasQCmzr6=GSpTZXoyjJuz00Q@mail.gmail.com>
On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote:
> On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
> > On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> [...]
> >>
> >> My point is that all of these need some way to handle configuration
> >> and inheritance, and I don't think that a bunch of per-task prctls is
> >> the right way. As just an example, saying that interactive users can
> >> autoload modules but other users can't, or that certain systemd
> >> services can, etc, might be nice. Linus already complained that he
> >> (i.e. user "torvalds" or whatever) should be able to profile the
> >> kernel but that other uids should not be able to.
> >
> > Neat, maybe this could already be achieved with this interface and
> > systemd-logind, "ModulesAutoloadUsers=andy" in logind.conf where
> > "andy" is the only logged-in user able to trigger and autoload kernel
> > modules. However maybe we should not restrict too much other bits or
> > functionality of the other users, please let me will follow up later
> > on it.
> >
> >> I personally like my implicit_rights idea, and it might be interesting
> >> to prototype it.
> >
>
> Andy following on the idea of per user settings, I'm curious did you
> manage to make some advance on how to store the user settings ? the
> user database format is old and not extensible, there was cgmanager or
(v2 is under very very early consideration, would love to stay in the loop
as this is considered)
> other libcgroup but for resources, and no simple thing for such
> restrictions example: "RestrictLinuxModules=user" that will prevent
> such users from making/loading extra Linux features/modules that are
> not already available...
>
> Thanks!
>
> --
> tixxdz
WARNING: multiple messages have this Message-ID (diff)
From: serge@hallyn.com (Serge E. Hallyn)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Thu, 4 May 2017 09:58:33 -0500 [thread overview]
Message-ID: <20170504145832.GA28002@mail.hallyn.com> (raw)
In-Reply-To: <CAEiveUf4p1A1fggwibN+kJW7ruasQCmzr6=GSpTZXoyjJuz00Q@mail.gmail.com>
On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote:
> On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
> > On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> [...]
> >>
> >> My point is that all of these need some way to handle configuration
> >> and inheritance, and I don't think that a bunch of per-task prctls is
> >> the right way. As just an example, saying that interactive users can
> >> autoload modules but other users can't, or that certain systemd
> >> services can, etc, might be nice. Linus already complained that he
> >> (i.e. user "torvalds" or whatever) should be able to profile the
> >> kernel but that other uids should not be able to.
> >
> > Neat, maybe this could already be achieved with this interface and
> > systemd-logind, "ModulesAutoloadUsers=andy" in logind.conf where
> > "andy" is the only logged-in user able to trigger and autoload kernel
> > modules. However maybe we should not restrict too much other bits or
> > functionality of the other users, please let me will follow up later
> > on it.
> >
> >> I personally like my implicit_rights idea, and it might be interesting
> >> to prototype it.
> >
>
> Andy following on the idea of per user settings, I'm curious did you
> manage to make some advance on how to store the user settings ? the
> user database format is old and not extensible, there was cgmanager or
(v2 is under very very early consideration, would love to stay in the loop
as this is considered)
> other libcgroup but for resources, and no simple thing for such
> restrictions example: "RestrictLinuxModules=user" that will prevent
> such users from making/loading extra Linux features/modules that are
> not already available...
>
> Thanks!
>
> --
> tixxdz
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Djalal Harouni <tixxdz@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LSM List <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Dongsu Park <dpark@posteo.net>,
Casey Schaufler <casey@schaufler-ca.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <paul@paul-moore.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
belakhdar abdeldjalil <zendyani@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: [kernel-hardening] Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Thu, 4 May 2017 09:58:33 -0500 [thread overview]
Message-ID: <20170504145832.GA28002@mail.hallyn.com> (raw)
In-Reply-To: <CAEiveUf4p1A1fggwibN+kJW7ruasQCmzr6=GSpTZXoyjJuz00Q@mail.gmail.com>
On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote:
> On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
> > On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> [...]
> >>
> >> My point is that all of these need some way to handle configuration
> >> and inheritance, and I don't think that a bunch of per-task prctls is
> >> the right way. As just an example, saying that interactive users can
> >> autoload modules but other users can't, or that certain systemd
> >> services can, etc, might be nice. Linus already complained that he
> >> (i.e. user "torvalds" or whatever) should be able to profile the
> >> kernel but that other uids should not be able to.
> >
> > Neat, maybe this could already be achieved with this interface and
> > systemd-logind, "ModulesAutoloadUsers=andy" in logind.conf where
> > "andy" is the only logged-in user able to trigger and autoload kernel
> > modules. However maybe we should not restrict too much other bits or
> > functionality of the other users, please let me will follow up later
> > on it.
> >
> >> I personally like my implicit_rights idea, and it might be interesting
> >> to prototype it.
> >
>
> Andy following on the idea of per user settings, I'm curious did you
> manage to make some advance on how to store the user settings ? the
> user database format is old and not extensible, there was cgmanager or
(v2 is under very very early consideration, would love to stay in the loop
as this is considered)
> other libcgroup but for resources, and no simple thing for such
> restrictions example: "RestrictLinuxModules=user" that will prevent
> such users from making/loading extra Linux features/modules that are
> not already available...
>
> Thanks!
>
> --
> tixxdz
next prev parent reply other threads:[~2017-05-04 14:59 UTC|newest]
Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-19 22:20 [PATCH v3 0/2] modules:capabilities: automatic module loading restrictions Djalal Harouni
2017-04-19 22:20 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` [PATCH v3 1/2] modules:capabilities: automatic module loading restriction Djalal Harouni
2017-04-19 22:20 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 23:16 ` Andy Lutomirski
2017-04-19 23:16 ` [kernel-hardening] " Andy Lutomirski
2017-04-19 23:16 ` Andy Lutomirski
2017-04-19 23:16 ` Andy Lutomirski
2017-04-20 2:22 ` Ben Hutchings
2017-04-20 2:22 ` [kernel-hardening] " Ben Hutchings
2017-04-20 2:22 ` Ben Hutchings
2017-04-20 12:44 ` [kernel-hardening] " Djalal Harouni
2017-04-20 12:44 ` Djalal Harouni
2017-04-20 12:44 ` Djalal Harouni
2017-04-20 15:02 ` Ben Hutchings
2017-04-20 15:02 ` Ben Hutchings
2017-04-20 15:02 ` Ben Hutchings
2017-04-20 20:39 ` [kernel-hardening] " Djalal Harouni
2017-04-20 20:39 ` Djalal Harouni
2017-04-20 20:39 ` Djalal Harouni
2017-04-20 21:28 ` Kees Cook
2017-04-20 21:28 ` Kees Cook
2017-04-20 21:28 ` Kees Cook
2017-04-20 21:28 ` Kees Cook
2017-04-19 22:20 ` [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction Djalal Harouni
2017-04-19 22:20 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:38 ` Djalal Harouni
2017-04-19 22:38 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:38 ` Djalal Harouni
2017-04-19 22:38 ` Djalal Harouni
2017-04-19 23:15 ` Andy Lutomirski
2017-04-19 23:15 ` [kernel-hardening] " Andy Lutomirski
2017-04-19 23:15 ` Andy Lutomirski
2017-04-19 23:15 ` Andy Lutomirski
2017-04-19 23:43 ` Kees Cook
2017-04-19 23:43 ` [kernel-hardening] " Kees Cook
2017-04-19 23:43 ` Kees Cook
2017-04-19 23:43 ` Kees Cook
2017-04-20 2:41 ` Andy Lutomirski
2017-04-20 2:41 ` [kernel-hardening] " Andy Lutomirski
2017-04-20 2:41 ` Andy Lutomirski
2017-04-20 2:41 ` Andy Lutomirski
2017-04-21 23:19 ` Kees Cook
2017-04-21 23:19 ` [kernel-hardening] " Kees Cook
2017-04-21 23:19 ` Kees Cook
2017-04-21 23:19 ` Kees Cook
2017-04-21 23:28 ` Andy Lutomirski
2017-04-21 23:28 ` [kernel-hardening] " Andy Lutomirski
2017-04-21 23:28 ` Andy Lutomirski
2017-04-21 23:28 ` Andy Lutomirski
2017-04-21 23:40 ` Kees Cook
2017-04-21 23:40 ` [kernel-hardening] " Kees Cook
2017-04-21 23:40 ` Kees Cook
2017-04-21 23:40 ` Kees Cook
2017-04-21 23:51 ` Andy Lutomirski
2017-04-21 23:51 ` [kernel-hardening] " Andy Lutomirski
2017-04-21 23:51 ` Andy Lutomirski
2017-04-21 23:51 ` Andy Lutomirski
2017-04-22 0:12 ` Djalal Harouni
2017-04-22 0:12 ` [kernel-hardening] " Djalal Harouni
2017-04-22 0:12 ` Djalal Harouni
2017-04-22 0:12 ` Djalal Harouni
2017-04-22 1:19 ` Djalal Harouni
2017-04-22 1:19 ` [kernel-hardening] " Djalal Harouni
2017-04-22 1:19 ` Djalal Harouni
2017-04-22 1:19 ` Djalal Harouni
2017-04-22 6:51 ` Andy Lutomirski
2017-04-22 6:51 ` [kernel-hardening] " Andy Lutomirski
2017-04-22 6:51 ` Andy Lutomirski
2017-04-22 6:51 ` Andy Lutomirski
2017-04-22 19:29 ` Kees Cook
2017-04-22 19:29 ` [kernel-hardening] " Kees Cook
2017-04-22 19:29 ` Kees Cook
2017-04-22 19:29 ` Kees Cook
2017-04-24 14:25 ` Djalal Harouni
2017-04-24 14:25 ` [kernel-hardening] " Djalal Harouni
2017-04-24 14:25 ` Djalal Harouni
2017-04-24 14:25 ` Djalal Harouni
2017-04-24 18:02 ` Kees Cook
2017-04-24 18:02 ` [kernel-hardening] " Kees Cook
2017-04-24 18:02 ` Kees Cook
2017-04-24 18:02 ` Kees Cook
2017-04-24 18:35 ` Djalal Harouni
2017-04-24 18:35 ` [kernel-hardening] " Djalal Harouni
2017-04-24 18:35 ` Djalal Harouni
2017-04-24 18:35 ` Djalal Harouni
2017-04-21 23:52 ` Casey Schaufler
2017-04-21 23:52 ` [kernel-hardening] " Casey Schaufler
2017-04-21 23:52 ` Casey Schaufler
2017-04-21 23:52 ` Casey Schaufler
2017-04-22 0:00 ` Andy Lutomirski
2017-04-22 0:00 ` [kernel-hardening] " Andy Lutomirski
2017-04-22 0:00 ` Andy Lutomirski
2017-04-22 0:00 ` Andy Lutomirski
2017-04-22 0:13 ` Casey Schaufler
2017-04-22 0:13 ` [kernel-hardening] " Casey Schaufler
2017-04-22 0:13 ` Casey Schaufler
2017-04-22 0:13 ` Casey Schaufler
2017-04-22 6:45 ` Andy Lutomirski
2017-04-22 6:45 ` [kernel-hardening] " Andy Lutomirski
2017-04-22 6:45 ` Andy Lutomirski
2017-04-22 6:45 ` Andy Lutomirski
2017-04-22 12:17 ` Djalal Harouni
2017-04-22 12:17 ` [kernel-hardening] " Djalal Harouni
2017-04-22 12:17 ` Djalal Harouni
2017-04-22 12:17 ` Djalal Harouni
2017-05-04 13:07 ` Djalal Harouni
2017-05-04 13:07 ` [kernel-hardening] " Djalal Harouni
2017-05-04 13:07 ` Djalal Harouni
2017-05-04 13:07 ` Djalal Harouni
2017-05-04 14:58 ` Serge E. Hallyn [this message]
2017-05-04 14:58 ` [kernel-hardening] " Serge E. Hallyn
2017-05-04 14:58 ` Serge E. Hallyn
2017-05-04 14:58 ` Serge E. Hallyn
2017-05-05 13:06 ` Djalal Harouni
2017-05-05 13:06 ` [kernel-hardening] " Djalal Harouni
2017-05-05 13:06 ` Djalal Harouni
2017-05-05 13:06 ` Djalal Harouni
2017-05-05 16:18 ` Andy Lutomirski
2017-05-05 16:18 ` [kernel-hardening] " Andy Lutomirski
2017-05-05 16:18 ` Andy Lutomirski
2017-05-05 16:18 ` Andy Lutomirski
2017-04-20 1:57 ` kbuild test robot
2017-04-20 1:57 ` [kernel-hardening] " kbuild test robot
2017-04-20 1:57 ` kbuild test robot
2017-04-20 1:57 ` kbuild test robot
2017-04-24 4:29 ` Rusty Russell
2017-04-24 4:29 ` [kernel-hardening] " Rusty Russell
2017-04-24 4:29 ` Rusty Russell
2017-04-24 4:29 ` Rusty Russell
2017-04-26 9:06 ` Djalal Harouni
2017-04-26 9:06 ` [kernel-hardening] " Djalal Harouni
2017-04-26 9:06 ` Djalal Harouni
2017-04-27 2:07 ` Rusty Russell
2017-04-27 2:07 ` [kernel-hardening] " Rusty Russell
2017-04-27 2:07 ` Rusty Russell
2017-04-27 2:07 ` Rusty Russell
2017-04-27 13:16 ` Djalal Harouni
2017-04-27 13:16 ` [kernel-hardening] " Djalal Harouni
2017-04-27 13:16 ` Djalal Harouni
2017-04-27 13:16 ` Djalal Harouni
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=20170504145832.GA28002@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=corbet@lwn.net \
--cc=dpark@posteo.net \
--cc=gregkh@linuxfoundation.org \
--cc=james.l.morris@oracle.com \
--cc=jeyu@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mchehab@kernel.org \
--cc=mingo@kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=tixxdz@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=zendyani@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.