From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Mickaël Salaün" <mic@digikod.net>,
"Tetsuo Handa" <penguin-kernel@I-love.SAKURA.ne.jp>,
keescook@chromium.org, matt@nmatt.com
Cc: jason@perfinion.com, linux-security-module@vger.kernel.org,
Daniel Micay <danielmicay@gmail.com>,
kernel-hardening <kernel-hardening@lists.openwall.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] shebang: restrict python interactive prompt/interpreter
Date: Mon, 12 Jun 2017 10:27:24 -0400 [thread overview]
Message-ID: <1497277644.21594.319.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <1497234757.21594.280.camel@linux.vnet.ibm.com>
On Sun, 2017-06-11 at 22:32 -0400, Mimi Zohar wrote:
> On Sun, 2017-06-11 at 13:44 +0200, Mickaël Salaün wrote:
> > Using filesystem xattr seems like a good idea for this kind of
> > exceptions and instead of a hardcoded interpreter path. Something like
> > "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI)
> > and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to
> > configure a security policy for some binaries. This could also be
> > protected by IMA/EVM, if needed.
>
> Checking for the existence of an xattr without caching is relatively
> slow. I'm not sure that we would want to go this route.
For identifying interpreters, xattrs would be too slow (without
caching results), but once identified, using xattrs as you suggested,
for specifying how interpreters can be invoked and limiting
environment variables, is a good idea. Perhaps the two xattrs could
be combined?
Mimi
next prev parent reply other threads:[~2017-06-12 14:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201706100041.GFH78616.OFtOHFJSLQOMVF@I-love.SAKURA.ne.jp>
[not found] ` <754b78d1-f7f9-58bd-bf74-fea9e105649a@nmatt.com>
[not found] ` <20170609164315.GA1141@meriadoc.perfinion.com>
[not found] ` <d84aaf19-307b-4b60-df74-4fb43a218c9c@nmatt.com>
[not found] ` <CAGXu5jJt5MRU3ZdKABEbLt4qe-cCLxEm5tMH9SdUh=rtdLUV1w@mail.gmail.com>
[not found] ` <201706101427.EEG90168.OtFFHSFMOVOJQL@I-love.SAKURA.ne.jp>
2017-06-11 11:44 ` [PATCH v1] shebang: restrict python interactive prompt/interpreter Mickaël Salaün
2017-06-12 2:32 ` Mimi Zohar
2017-06-12 14:27 ` Mimi Zohar [this message]
2017-06-13 20:59 ` Mickaël Salaün
2017-06-14 14:10 ` Alan Cox
2017-06-14 20:37 ` [kernel-hardening] " Boris Lukashev
2017-06-13 20:59 ` Mickaël Salaün
2017-06-13 21:44 ` [kernel-hardening] " Casey Schaufler
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=1497277644.21594.319.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=danielmicay@gmail.com \
--cc=jason@perfinion.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matt@nmatt.com \
--cc=mic@digikod.net \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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