* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Matthew Wilcox @ 2018-12-13 12:16 UTC (permalink / raw)
To: Mimi Zohar
Cc: Mickaël Salaün, linux-kernel, Al Viro, James Morris,
Jonathan Corbet, Kees Cook, Matthew Garrett, Michael Kerrisk,
Mickaël Salaün, Philippe Trébuchet, Shuah Khan,
Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel
In-Reply-To: <1544699060.6703.11.camel@linux.ibm.com>
On Thu, Dec 13, 2018 at 06:04:20AM -0500, Mimi Zohar wrote:
> > I don't have a problem with the concept, but we're running low on O_ bits.
> > Does this have to be done before the process gets a file descriptor,
> > or could we have a new syscall? Since we're going to be changing the
> > interpreters anyway, it doesn't seem like too much of an imposition to
> > ask them to use:
> >
> > int verify_for_exec(int fd)
> >
> > instead of adding an O_MAYEXEC.
>
> The indication needs to be set during file open, before the open
> returns to the caller. This is the point where ima_file_check()
> verifies the file's signature. On failure, access to the file is
> denied.
I understand that's what happens today, but do we need to do it that way?
There's no harm in the interpreter having an fd to a file if it knows
not to execute it. This is different from a program opening a file and
having the LSM deny access to it because it violates the security model.
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Kevin Easton @ 2018-12-13 12:12 UTC (permalink / raw)
To: Richard Weinberger
Cc: glaubitz, Andy Lutomirski, x86, LKML, open list:ABI/API,
H. Peter Anvin, Peter Zijlstra, Borislav Petkov, fweimer,
Mike Frysinger, H.J. Lu, dalias, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <CAFLxGvy2sMW1nyMpxGN7xHPdUea713g89MdE3EcUNHJDCvZ3jA@mail.gmail.com>
On Thu, Dec 13, 2018 at 10:05:14AM +0100, Richard Weinberger wrote:
> On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton <kevin@guarana.org> wrote:
> >
> > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> > ...
> > > I can't say anything about the syscall interface. However, what I do know
> > > is that the weird combination of a 32-bit userland with a 64-bit kernel
> > > interface is sometimes causing issues. For example, application code usually
> > > expects things like time_t to be 32-bit on a 32-bit system. However, this
> > > isn't the case for x32 which is why code fails to build.
> >
> > OpenBSD and NetBSD both have 64-bit time_t on 32-bit systems and have
> > had for four or five years at this point.
>
> They can also do flag-day changes and break existing applications, Linux not.
Sure, but the point is that most widely-used software has probably by
now come in to contact with systems where time_t is bigger than long.
- Kevin
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Florian Weimer @ 2018-12-13 11:26 UTC (permalink / raw)
To: Mimi Zohar
Cc: Matthew Wilcox, Mickaël Salaün, linux-kernel, Al Viro,
James Morris, Jonathan Corbet, Kees Cook, Matthew Garrett,
Michael Kerrisk, Mickaël Salaün,
Philippe Trébuchet, Shuah Khan, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module
In-Reply-To: <1544699060.6703.11.camel@linux.ibm.com>
* Mimi Zohar:
> The indication needs to be set during file open, before the open
> returns to the caller. This is the point where ima_file_check()
> verifies the file's signature. On failure, access to the file is
> denied.
Does this verification happen for open with O_PATH?
Thanks,
Florian
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Mimi Zohar @ 2018-12-13 11:04 UTC (permalink / raw)
To: Matthew Wilcox, Mickaël Salaün
Cc: linux-kernel, Al Viro, James Morris, Jonathan Corbet, Kees Cook,
Matthew Garrett, Michael Kerrisk, Mickaël Salaün,
Philippe Trébuchet, Shuah Khan, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20181213030228.GM6830@bombadil.infradead.org>
On Wed, 2018-12-12 at 19:02 -0800, Matthew Wilcox wrote:
> On Wed, Dec 12, 2018 at 09:17:07AM +0100, Mickaël Salaün wrote:
> > The goal of this patch series is to control script interpretation. A
> > new O_MAYEXEC flag used by sys_open() is added to enable userland script
> > interpreter to delegate to the kernel (and thus the system security
> > policy) the permission to interpret scripts or other files containing
> > what can be seen as commands.
>
> I don't have a problem with the concept, but we're running low on O_ bits.
> Does this have to be done before the process gets a file descriptor,
> or could we have a new syscall? Since we're going to be changing the
> interpreters anyway, it doesn't seem like too much of an imposition to
> ask them to use:
>
> int verify_for_exec(int fd)
>
> instead of adding an O_MAYEXEC.
The indication needs to be set during file open, before the open
returns to the caller. This is the point where ima_file_check()
verifies the file's signature. On failure, access to the file is
denied.
Mimi
^ permalink raw reply
* Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Matthew Bobrowski @ 2018-12-13 9:47 UTC (permalink / raw)
To: Jan Kara
Cc: Mickaël Salaün, linux-kernel, Al Viro, James Morris,
Jonathan Corbet, Kees Cook, Matthew Garrett, Michael Kerrisk,
Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
Shuah Khan, Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module
In-Reply-To: <20181212144306.GA19945@quack2.suse.cz>
On Wed, Dec 12, 2018 at 03:43:06PM +0100, Jan Kara wrote:
> > When the O_MAYEXEC flag is passed, sys_open() may be subject to
> > additional restrictions depending on a security policy implemented by an
> > LSM through the inode_permission hook.
> >
> > The underlying idea is to be able to restrict scripts interpretation
> > according to a policy defined by the system administrator. For this to
> > be possible, script interpreters must use the O_MAYEXEC flag
> > appropriately. To be fully effective, these interpreters also need to
> > handle the other ways to execute code (for which the kernel can't help):
> > command line parameters (e.g., option -e for Perl), module loading
> > (e.g., option -m for Python), stdin, file sourcing, environment
> > variables, configuration files... According to the threat model, it may
> > be acceptable to allow some script interpreters (e.g. Bash) to interpret
> > commands from stdin, may it be a TTY or a pipe, because it may not be
> > enough to (directly) perform syscalls.
> >
> > A simple security policy implementation is available in a following
> > patch for Yama.
> >
> > This is an updated subset of the patch initially written by Vincent
> > Strubel for CLIP OS:
> > https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch
> > This patch has been used for more than 10 years with customized script
> > interpreters. Some examples can be found here:
> > https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
> >
> > Signed-off-by: Mickaël Salaün <mic@digikod.net>
> > Signed-off-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
> > Signed-off-by: Vincent Strubel <vincent.strubel@ssi.gouv.fr>
> > Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
>
> ...
>
> > diff --git a/fs/open.c b/fs/open.c
> > index 0285ce7dbd51..75479b79a58f 100644
> > --- a/fs/open.c
> > +++ b/fs/open.c
> > @@ -974,6 +974,10 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o
> > if (flags & O_APPEND)
> > acc_mode |= MAY_APPEND;
> >
> > + /* Check execution permissions on open. */
> > + if (flags & O_MAYEXEC)
> > + acc_mode |= MAY_OPENEXEC;
> > +
> > op->acc_mode = acc_mode;
> >
> > op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN;
>
> I don't feel experienced enough in security to tell whether we want this
> functionality or not. But if we do this, shouldn't we also set FMODE_EXEC
> on the resulting struct file? That way also security_file_open() can be
> used to arbitrate such executable opens and in particular
> fanotify permission event FAN_OPEN_EXEC will get properly generated which I
> guess is desirable (support for it is sitting in my tree waiting for the
> merge window) - adding some audit people involved in FAN_OPEN_EXEC to
> CC. Just an idea...
If I'm understanding this patch series correctly, without an enforced LSM
policy there's realistically no added benefit from a security perspective,
right? Also, I'm in agreement with what Jan has mentioned in regards to setting
the __FMODE_EXEC flag when O_MAYEXEC has been specified. This is something that
would work quite nicely in conjunction with some of the new file access
notification events.
Rather than setting it on the resulting struct file, couldn't they simply
incorporate it as part of op->open_flags when flags & O_MAYEXEC? Not entirely
sure whether this is what you actually meant or not though? Pretty much the
same as a call to exec(2)/execat(2) when it builds its open_flags.
--
Matthew Bobrowski
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Richard Weinberger @ 2018-12-13 9:05 UTC (permalink / raw)
To: kevin
Cc: glaubitz, Andy Lutomirski, x86, LKML, open list:ABI/API,
H. Peter Anvin, Peter Zijlstra, Borislav Petkov, fweimer,
Mike Frysinger, H.J. Lu, dalias, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <20181213050313.GA21201@ip-172-31-15-78>
On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton <kevin@guarana.org> wrote:
>
> On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> ...
> > I can't say anything about the syscall interface. However, what I do know
> > is that the weird combination of a 32-bit userland with a 64-bit kernel
> > interface is sometimes causing issues. For example, application code usually
> > expects things like time_t to be 32-bit on a 32-bit system. However, this
> > isn't the case for x32 which is why code fails to build.
>
> OpenBSD and NetBSD both have 64-bit time_t on 32-bit systems and have
> had for four or five years at this point.
They can also do flag-day changes and break existing applications, Linux not.
--
Thanks,
//richard
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Florian Weimer @ 2018-12-13 5:22 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mickaël Salaün, linux-kernel, Al Viro, James Morris,
Jonathan Corbet, Kees Cook, Matthew Garrett, Michael Kerrisk,
Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
Shuah Khan, Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module
In-Reply-To: <20181213030228.GM6830@bombadil.infradead.org>
* Matthew Wilcox:
> On Wed, Dec 12, 2018 at 09:17:07AM +0100, Mickaël Salaün wrote:
>> The goal of this patch series is to control script interpretation. A
>> new O_MAYEXEC flag used by sys_open() is added to enable userland script
>> interpreter to delegate to the kernel (and thus the system security
>> policy) the permission to interpret scripts or other files containing
>> what can be seen as commands.
>
> I don't have a problem with the concept, but we're running low on O_ bits.
> Does this have to be done before the process gets a file descriptor,
> or could we have a new syscall? Since we're going to be changing the
> interpreters anyway, it doesn't seem like too much of an imposition to
> ask them to use:
>
> int verify_for_exec(int fd)
>
> instead of adding an O_MAYEXEC.
Will this work for auditing?
Maybe add an interface which explicitly upgrades O_PATH descriptors, and
give that a separate flag argument? I suppose that would be more
friendly to auditing.
Thanks,
Florian
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Florian Weimer @ 2018-12-13 5:13 UTC (permalink / raw)
To: James Morris
Cc: Mickaël Salaün, linux-kernel, Al Viro, Jonathan Corbet,
Kees Cook, Matthew Garrett, Michael Kerrisk,
Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
Shuah Khan, Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel
In-Reply-To: <alpine.LRH.2.21.1812131039400.7600@namei.org>
* James Morris:
> On Wed, 12 Dec 2018, Florian Weimer wrote:
>
>> * James Morris:
>>
>> > If you're depending on the script interpreter to flag that the user may
>> > execute code, this seems to be equivalent in security terms to depending
>> > on the user. e.g. what if the user uses ptrace and clears O_MAYEXEC?
>>
>> The argument I've heard is this: Using ptrace (and adding the +x
>> attribute) are auditable events.
>
> I guess you could also preload a modified libc which strips the flag.
My understanding is that this new libc would have to come somewhere, and
making it executable would be an auditable even as well.
Thanks,
Florian
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Kevin Easton @ 2018-12-13 5:03 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Andy Lutomirski, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Florian Weimer, Mike Frysinger,
H. J. Lu, Rich Felker, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <70bb54b2-8ed3-b5ee-c02d-6ef66c4f27eb@physik.fu-berlin.de>
On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
...
> I can't say anything about the syscall interface. However, what I do know
> is that the weird combination of a 32-bit userland with a 64-bit kernel
> interface is sometimes causing issues. For example, application code usually
> expects things like time_t to be 32-bit on a 32-bit system. However, this
> isn't the case for x32 which is why code fails to build.
OpenBSD and NetBSD both have 64-bit time_t on 32-bit systems and have
had for four or five years at this point.
- Kevin
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Matthew Wilcox @ 2018-12-13 3:02 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Al Viro, James Morris, Jonathan Corbet, Kees Cook,
Matthew Garrett, Michael Kerrisk, Mickaël Salaün,
Mimi Zohar, Philippe Trébuchet, Shuah Khan,
Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel
In-Reply-To: <20181212081712.32347-1-mic@digikod.net>
On Wed, Dec 12, 2018 at 09:17:07AM +0100, Mickaël Salaün wrote:
> The goal of this patch series is to control script interpretation. A
> new O_MAYEXEC flag used by sys_open() is added to enable userland script
> interpreter to delegate to the kernel (and thus the system security
> policy) the permission to interpret scripts or other files containing
> what can be seen as commands.
I don't have a problem with the concept, but we're running low on O_ bits.
Does this have to be done before the process gets a file descriptor,
or could we have a new syscall? Since we're going to be changing the
interpreters anyway, it doesn't seem like too much of an imposition to
ask them to use:
int verify_for_exec(int fd)
instead of adding an O_MAYEXEC.
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: James Morris @ 2018-12-12 23:40 UTC (permalink / raw)
To: Florian Weimer
Cc: Mickaël Salaün, linux-kernel, Al Viro, Jonathan Corbet,
Kees Cook, Matthew Garrett, Michael Kerrisk,
Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
Shuah Khan, Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel
In-Reply-To: <87lg4upkpv.fsf@oldenburg2.str.redhat.com>
On Wed, 12 Dec 2018, Florian Weimer wrote:
> * James Morris:
>
> > If you're depending on the script interpreter to flag that the user may
> > execute code, this seems to be equivalent in security terms to depending
> > on the user. e.g. what if the user uses ptrace and clears O_MAYEXEC?
>
> The argument I've heard is this: Using ptrace (and adding the +x
> attribute) are auditable events.
I guess you could also preload a modified libc which strips the flag.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH -manpage 2/2] memfd_create.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal
From: Joel Fernandes (Google) @ 2018-12-12 22:05 UTC (permalink / raw)
To: linux-man
Cc: Joel Fernandes (Google), Andrew Morton, Andy Lutomirski, dancol,
Hugh Dickins, Jann Horn, John Stultz, linux-api, linux-kernel,
linux-mm, Marc-André Lureau, Matthew Wilcox, Mike Kravetz,
Shuah Khan, Stephen Rothwell
In-Reply-To: <20181212220514.205269-1-joel@joelfernandes.org>
More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-joel@joelfernandes.org/T/#t
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
man2/memfd_create.2 | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/man2/memfd_create.2 b/man2/memfd_create.2
index 3cd392d1b4d9..fce2bf8d0fff 100644
--- a/man2/memfd_create.2
+++ b/man2/memfd_create.2
@@ -280,7 +280,15 @@ in order to restrict further modifications on the file.
(If placing the seal
.BR F_SEAL_WRITE ,
then it will be necessary to first unmap the shared writable mapping
-created in the previous step.)
+created in the previous step. Otherwise, behavior similar to
+.BR F_SEAL_WRITE
+can be achieved, by using
+.BR F_SEAL_FUTURE_WRITE
+which will prevent future writes via
+.BR mmap (2)
+and
+.BR write (2)
+from succeeding, while keeping existing shared writable mappings).
.IP 4.
A second process obtains a file descriptor for the
.BR tmpfs (5)
@@ -425,6 +433,7 @@ main(int argc, char *argv[])
fprintf(stderr, "\\t\\tg \- F_SEAL_GROW\\n");
fprintf(stderr, "\\t\\ts \- F_SEAL_SHRINK\\n");
fprintf(stderr, "\\t\\tw \- F_SEAL_WRITE\\n");
+ fprintf(stderr, "\\t\\tW \- F_SEAL_FUTURE_WRITE\\n");
fprintf(stderr, "\\t\\tS \- F_SEAL_SEAL\\n");
exit(EXIT_FAILURE);
}
@@ -463,6 +472,8 @@ main(int argc, char *argv[])
seals |= F_SEAL_SHRINK;
if (strchr(seals_arg, \(aqw\(aq) != NULL)
seals |= F_SEAL_WRITE;
+ if (strchr(seals_arg, \(aqW\(aq) != NULL)
+ seals |= F_SEAL_FUTURE_WRITE;
if (strchr(seals_arg, \(aqS\(aq) != NULL)
seals |= F_SEAL_SEAL;
@@ -518,6 +529,8 @@ main(int argc, char *argv[])
printf(" GROW");
if (seals & F_SEAL_WRITE)
printf(" WRITE");
+ if (seals & F_SEAL_FUTURE_WRITE)
+ printf(" FUTURE_WRITE");
if (seals & F_SEAL_SHRINK)
printf(" SHRINK");
printf("\\n");
--
2.20.0.rc1.387.gf8505762e3-goog
^ permalink raw reply related
* [PATCH -manpage 1/2] fcntl.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal
From: Joel Fernandes (Google) @ 2018-12-12 22:05 UTC (permalink / raw)
To: linux-man
Cc: Joel Fernandes (Google), Andrew Morton, Andy Lutomirski, dancol,
Hugh Dickins, Jann Horn, John Stultz, linux-api, linux-kernel,
linux-mm, Marc-André Lureau, Matthew Wilcox, Mike Kravetz,
Shuah Khan, Stephen Rothwell
More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-joel@joelfernandes.org/T/#t
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
man2/fcntl.2 | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/man2/fcntl.2 b/man2/fcntl.2
index 03533d65b49d..54772f94964c 100644
--- a/man2/fcntl.2
+++ b/man2/fcntl.2
@@ -1525,6 +1525,21 @@ Furthermore, if there are any asynchronous I/O operations
.RB ( io_submit (2))
pending on the file,
all outstanding writes will be discarded.
+.TP
+.BR F_SEAL_FUTURE_WRITE
+If this seal is set, the contents of the file can be modified only from
+existing writeable mappings that were created prior to the seal being set.
+Any attempt to create a new writeable mapping on the memfd via
+.BR mmap (2)
+will fail with
+.BR EPERM.
+Also any attempts to write to the memfd via
+.BR write (2)
+will fail with
+.BR EPERM.
+This is useful in situations where existing writable mapped regions need to be
+kept intact while preventing any future writes. For example, to share a
+read-only memory buffer to other processes that only the sender can write to.
.\"
.SS File read/write hints
Write lifetime hints can be used to inform the kernel about the relative
--
2.20.0.rc1.387.gf8505762e3-goog
^ permalink raw reply related
* Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Mimi Zohar @ 2018-12-12 20:42 UTC (permalink / raw)
To: Jan Kara, Mickaël Salaün
Cc: linux-kernel, Al Viro, James Morris, Jonathan Corbet, Kees Cook,
Matthew Garrett, Michael Kerrisk, Mickaël Salaün,
Philippe Trébuchet, Shuah Khan, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel, sgrubb, Matthew Bobrowski
In-Reply-To: <20181212144306.GA19945@quack2.suse.cz>
On Wed, 2018-12-12 at 15:43 +0100, Jan Kara wrote:
> > diff --git a/fs/open.c b/fs/open.c
> > index 0285ce7dbd51..75479b79a58f 100644
> > --- a/fs/open.c
> > +++ b/fs/open.c
> > @@ -974,6 +974,10 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o
> > if (flags & O_APPEND)
> > acc_mode |= MAY_APPEND;
> >
> > + /* Check execution permissions on open. */
> > + if (flags & O_MAYEXEC)
> > + acc_mode |= MAY_OPENEXEC;
> > +
> > op->acc_mode = acc_mode;
> >
> > op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN;
>
> I don't feel experienced enough in security to tell whether we want this
> functionality or not. But if we do this, shouldn't we also set FMODE_EXEC
> on the resulting struct file? That way also security_file_open() can be
> used to arbitrate such executable opens and in particular
> fanotify permission event FAN_OPEN_EXEC will get properly generated which I
> guess is desirable (support for it is sitting in my tree waiting for the
> merge window) - adding some audit people involved in FAN_OPEN_EXEC to
> CC. Just an idea...
Assuming the interpreters are properly modified (and signed),
MAY_OPENEXEC closes a major IMA measurement/appraisal gap. The kernel
has no insight into the files that the interpreter is opening. Having
the interpreter annotate the file open, allows IMA to differentiate
scripts opening data files from code.
IMA policy rules could then be written requiring code to be signed.
Example IMA policy rules:
measure func=FILE_CHECK mask=MAY_OPENEXEC
appraise func=FILE_CHECK mask=MAY_OPENEXEC appraise_type=imasig
Mimi
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Florian Weimer @ 2018-12-12 20:13 UTC (permalink / raw)
To: James Morris
Cc: Mickaël Salaün, linux-kernel, Al Viro, Jonathan Corbet,
Kees Cook, Matthew Garrett, Michael Kerrisk,
Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
Shuah Khan, Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel
In-Reply-To: <alpine.LRH.2.21.1812130642250.29507@namei.org>
* James Morris:
> If you're depending on the script interpreter to flag that the user may
> execute code, this seems to be equivalent in security terms to depending
> on the user. e.g. what if the user uses ptrace and clears O_MAYEXEC?
The argument I've heard is this: Using ptrace (and adding the +x
attribute) are auditable events.
Florian
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: James Morris @ 2018-12-12 19:51 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Al Viro, Jonathan Corbet, Kees Cook,
Matthew Garrett, Michael Kerrisk, Mickaël Salaün,
Mimi Zohar, Philippe Trébuchet, Shuah Khan,
Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel
In-Reply-To: <20181212081712.32347-1-mic@digikod.net>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
On Wed, 12 Dec 2018, Mickaël Salaün wrote:
> Hi,
>
> The goal of this patch series is to control script interpretation. A
> new O_MAYEXEC flag used by sys_open() is added to enable userland script
> interpreter to delegate to the kernel (and thus the system security
> policy) the permission to interpret scripts or other files containing
> what can be seen as commands.
>
> The security policy is the responsibility of an LSM. A basic
> system-wide policy is implemented with Yama and configurable through a
> sysctl.
If you're depending on the script interpreter to flag that the user may
execute code, this seems to be equivalent in security terms to depending
on the user. e.g. what if the user uses ptrace and clears O_MAYEXEC?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Ivan Ivanov @ 2018-12-12 19:18 UTC (permalink / raw)
To: luto
Cc: joseph, arnd, tg, Linus Torvalds, x86, Linux Kernel Mailing List,
linux-api, hpa, peterz, bp, fweimer, vapier, hjl.tools, dalias,
x32, will.deacon, catalin.marinas
In-Reply-To: <CALCETrUzyEENFc8rgDnbx9U-tALR4sjKsORjAwTY5ko1zzAVsQ@mail.gmail.com>
My main reason on staying at Pentium 4 is that it does not contain
Intel ME backdoor (it came starting with Core 2 Duo)
ср, 12 дек. 2018 г. в 22:12, Andy Lutomirski <luto@kernel.org>:
>
> On Wed, Dec 12, 2018 at 10:50 AM Ivan Ivanov <qmastery16@gmail.com> wrote:
> >
> > Please don't drop x86 support from the Linux kernel ! You may not
> > realize it, but there are plenty of people who care about x86 systems.
> > I have a good old Pentium 4 based computer which is 32-bit, using it
> > for some weird Linux experiments + retro gaming, and if I can't run
> > new Linux kernels there - it would be SAD
>
> Just to clarify: no one is proposing to drop 32-bit hardware support
> or normal x86 compatibility support from new kernels.
>
> That being said, you should seriously consider replacing that P4.
> Unless you live somewhere with *very* cheap power or you barely use
> it, replacing it will pay for itself quite quickly.
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Andy Lutomirski @ 2018-12-12 19:12 UTC (permalink / raw)
To: qmastery16
Cc: Joseph S. Myers, Arnd Bergmann, tg, Andrew Lutomirski,
Linus Torvalds, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Florian Weimer, Mike Frysinger,
H. J. Lu, Rich Felker, x32, Will Deacon, Catalin Marinas
In-Reply-To: <CAAaskFA5cssU+fGAOUJO4u5XYBP6XYtSeWRhaSAr3BqOBTYjmw@mail.gmail.com>
On Wed, Dec 12, 2018 at 10:50 AM Ivan Ivanov <qmastery16@gmail.com> wrote:
>
> Please don't drop x86 support from the Linux kernel ! You may not
> realize it, but there are plenty of people who care about x86 systems.
> I have a good old Pentium 4 based computer which is 32-bit, using it
> for some weird Linux experiments + retro gaming, and if I can't run
> new Linux kernels there - it would be SAD
Just to clarify: no one is proposing to drop 32-bit hardware support
or normal x86 compatibility support from new kernels.
That being said, you should seriously consider replacing that P4.
Unless you live somewhere with *very* cheap power or you barely use
it, replacing it will pay for itself quite quickly.
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Ivan Ivanov @ 2018-12-12 18:50 UTC (permalink / raw)
To: joseph
Cc: arnd, tg, luto, Linus Torvalds, x86, Linux Kernel Mailing List,
linux-api, hpa, peterz, bp, fweimer, vapier, hjl.tools, dalias,
x32, will.deacon, catalin.marinas
In-Reply-To: <alpine.DEB.2.21.1812121811080.21643@digraph.polyomino.org.uk>
Please don't drop x86 support from the Linux kernel ! You may not
realize it, but there are plenty of people who care about x86 systems.
I have a good old Pentium 4 based computer which is 32-bit, using it
for some weird Linux experiments + retro gaming, and if I can't run
new Linux kernels there - it would be SAD
ср, 12 дек. 2018 г. в 21:15, Joseph Myers <joseph@codesourcery.com>:
>
> On Wed, 12 Dec 2018, Arnd Bergmann wrote:
>
> > > MIPS had o32, n32, n64 since like forever.
> >
> > o32 and n32 are practically the same, the only difference on the
> > syscall ABI that I can see are the actual syscall numbers, and
> > the 'struct sigcontext' definition.
>
> And for syscalls that have 64-bit arguments, n32 generally passes those in
> a single register (like n64), not pairs of registers (like o32). But,
> yes, userspace structure layout for n32 is generally much closer to o32
> than to n64.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Joseph Myers @ 2018-12-12 18:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: tg, Andy Lutomirski, Linus Torvalds, the arch/x86 maintainers,
Linux Kernel Mailing List, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Florian Weimer, vapier, H.J. Lu,
Rich Felker, x32, Will Deacon, Catalin Marinas
In-Reply-To: <CAK8P3a3yurujkdic98H02j0YfctSBf9NeXQreLZVhTzsttoc9g@mail.gmail.com>
On Wed, 12 Dec 2018, Arnd Bergmann wrote:
> > MIPS had o32, n32, n64 since like forever.
>
> o32 and n32 are practically the same, the only difference on the
> syscall ABI that I can see are the actual syscall numbers, and
> the 'struct sigcontext' definition.
And for syscalls that have 64-bit arguments, n32 generally passes those in
a single register (like n64), not pairs of registers (like o32). But,
yes, userspace structure layout for n32 is generally much closer to o32
than to n64.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Andy Lutomirski @ 2018-12-12 18:03 UTC (permalink / raw)
To: Rich Felker
Cc: Andrew Lutomirski, tg, Linus Torvalds, X86 ML, LKML, Linux API,
H. Peter Anvin, Peter Zijlstra, Borislav Petkov, Florian Weimer,
Mike Frysinger, H. J. Lu, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas
In-Reply-To: <20181212165237.GT23599@brightrain.aerifal.cx>
On Wed, Dec 12, 2018 at 8:52 AM Rich Felker <dalias@libc.org> wrote:
>
> On Wed, Dec 12, 2018 at 08:39:53AM -0800, Andy Lutomirski wrote:
> > > On Dec 11, 2018, at 6:33 PM, Thorsten Glaser <tg@mirbsd.de> wrote:
> > >
> > > Andy Lutomirski dixit:
> > >
> >
> > >
> > >> IMO the real right solution would be to push the whole problem to
> > >> userspace: get an ILP32 system working with almost or entirely LP64
> > >
> > > Is this a reflex of Linux kernel developers? ;-)
> > >
> > > I doubt that userspace is the right place for this, remember
> > > the recent glibc vs. syscalls debate. It would also need to
> > > multiply across various libcs.
> > >
> > >> How hard would it be to have __attribute__((ilp64)), with an optional
> > >> warning if any embedded structs are not ilp64? This plus a wrapper to
> > >
> > > You mean LP64. Impossible, because LP64 vs. ILP32 is not the only
> > > difference between amd64 and x32.
> >
> > I mean LP64. And I'm not suggesting that ILP32 is the only difference
> > between x32 and x86_64, nor am I suggesting that a technique like this
> > would implement x32 -- I'm suggesting it would implement something
> > better than x32.
> >
> > The kernel, as a practical matter, supports two ABIs on 64-bit builds:
> > LP64 and ILP32. ILP32 is what the kernel calls "compat". ("compat"
> > comes with other baggage -- it generally has a 32-bit signal frame,
> > syscall arguments are mostly limited to 32 bits, etc.) Allowing a
> > user program that runs in 64-bit mode to issue compat syscalls is not
> > really a big deal. x86_64 has allowed this forever using int $0x80 --
> > it's just slow. Adding a faster mechanism would be straightforward.
> > As I understand it, the arm64 ilp32 proposal involves using a genuine
> > ILP32 model for user code, so the syscalls will all (except for signal
> > handling) go through the compat path.
> >
> > x32 is not this at all. The kernel ABI part of x32 isn't ILP32. It's
> > IP32, 32-bit size_t, and *64-bit* long. The core kernel doesn't
> > really support this. The only good things I can think of about it are
> > that (a) it proves that somewhat odd ABIs are possible, at least in
> > principle, and (b) three users have come out of the woodwork to say
> > that they use it.
> >
> > I'm proposing another alternative. Given that x32 already proves that
> > the user bitness model doesn't have to match the kernel model (in x32,
> > user "long" is 32-bit but the kernel ABI "long" is 64-bit), I'm
> > proposing extending this to just make the kernel ABI be LP64. So
> > __kernel_size_t would be 64-bit and pointers in kernel data structures
> > would be 64-bit. In other words, most or all of the kernel ABI would
> > just match x86_64.
> >
> > As far as I can tell, the only thing that really needs unusual
> > toolchain features here is that C doesn't have an extra-wide pointer
> > type. The kernel headers would need a way to say "this pointer is
> > still logically a pointer, and user code may assume that it's 32 bits,
> > but it has 8-byte alignment."
>
> None of this works on the userspace/C side, nor should any attempt be
> made to make it work. Types fundamentally cannot have alignments
> larger than their size. If you want to make the alignment of some
> pointers 8, you have to make their size 8, and then you just have LP64
> again if you did it for all pointers.
>
> If on the other hand you tried to make just some pointers "wide
> pointers", you'd also be completely breaking the specified API
> contracts of standard interfaces. For example in struct iovec's
> iov_base, &foo->iov_base is no longer a valid pointer to an object of
> type void* that you can pass to interfaces expecting void**. Sloppy
> misunderstandings like what you're making now are exactly why x32 is
> already broken and buggy (&foo->tv_nsec already has wrong type for
> struct timespec foo).
I don't think it's quite that broken. For the struct iovec example,
we currently have:
struct iovec {
void *iov_base; /* Starting address */
size_t iov_len; /* Number of bytes to transfer */
};
we could have, instead: (pardon any whitespace damage)
struct iovec {
void *iov_base; /* Starting address */
uint32_t __pad0;
size_t iov_len; /* Number of bytes to transfer */
uint32_t __pad1;
} __attribute__((aligned(8));
or the same thing but where iov_len is uint64_t. A pointer to
iov_base still works exactly as expected. Something would need to be
done to ensure that the padding is all zeroed, which might be a real
problem.
No one wants to actually type all the macro gunk into the headers to
make this work, but this type of transformation is what I have in mind
when the compiler is asked to handle the headers. Or there could
potentially be a tool that automatically consumes the uapi headers and
spits out modified headers like this.
Realistically, I think a much better model would be to use true ILP32
code, where all the memory layouts in the uapi match i386.
> Unless it's a thin, "pure" library that doesn't need anything from
> libc, or needs sufficiently little that it could be satisfied by some
> shims, this would necessarily require having two libcs in the same
> process, which is not going to work.
>
>
That's a good point.
^ permalink raw reply
* Re: [PATCH v5 24/25] ptrace: add PTRACE_GET_SYSCALL_INFO request
From: Oleg Nesterov @ 2018-12-12 18:00 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: Andy Lutomirski, Elvira Khabirova, Eugene Syromyatnikov,
Kees Cook, Jann Horn, linux-api, strace-devel, linux-kernel
In-Reply-To: <20181211202709.GA3839@altlinux.org>
On 12/11, Dmitry V. Levin wrote:
>
> > > Still can't understand... are you saying that without (say) __pad2[4]
> > > sizeof(ptrace_syscall_info) or offsetofend(ptrace_syscall_info, seccomp)
> > > will depend on arch? Or what? I am just curious.
> >
> > Yes, without padding these sizes will depend on architecture:
>
> > $ cat t.c
> > #include <linux/types.h>
> > int main() {
> > struct s {
> > __u64 nr;
> > __u64 args[6];
> > __u32 ret_data;
> > };
> > return sizeof(struct s);
> > }
> >
> > $ gcc -m64 -Wall -O2 t.c && ./a.out; echo $?
> > 64
> > $ gcc -m32 -Wall -O2 t.c && ./a.out; echo $?
> > 60
> >
> > This happens because __u64 has 32-bit alignment on some 32-bit
> > architectures like x86.
> >
> > There is also m68k where __u32 has 16-bit alignment.
OK, thanks,
> Said that, I think it would be better if PTRACE_GET_SYSCALL_INFO
> did not take these trailing pads into account, e.g.
>
> - return offsetofend(struct ptrace_syscall_info, seccomp);
> + return offsetofend(struct ptrace_syscall_info, seccomp.ret_data);
> ...
> - return offsetofend(struct ptrace_syscall_info, exit);
> + return offsetofend(struct ptrace_syscall_info, exit.is_error);
>
> The reason is that it would allow to fill these trailing pads with
> something useful in the future.
Agreed.
But this way everything looks even more confusing. To me it would be
better to simply remove these pads, but I won't insist.
Oleg.
^ permalink raw reply
* Re: [RFC PATCH v1 3/5] Yama: Enforces noexec mounts or file executability through O_MAYEXEC
From: Jann Horn @ 2018-12-12 17:09 UTC (permalink / raw)
To: Mickaël Salaün
Cc: kernel list, Al Viro, James Morris, Jonathan Corbet, Kees Cook,
Matthew Garrett, Michael Kerrisk-manpages, mickael.salaun, zohar,
philippe.trebuchet, shuah, thibaut.sautereau, vincent.strubel,
yves-alexis.perez, Kernel Hardening, Linux API,
linux-security-module, linux-fsdevel
In-Reply-To: <20181212081712.32347-4-mic@digikod.net>
On Wed, Dec 12, 2018 at 9:18 AM Mickaël Salaün <mic@digikod.net> wrote:
> Enable to either propagate the mount options from the underlying VFS
> mount to prevent execution, or to propagate the file execute permission.
> This may allow a script interpreter to check execution permissions
> before reading commands from a file.
>
> The main goal is to be able to protect the kernel by restricting
> arbitrary syscalls that an attacker could perform with a crafted binary
> or certain script languages. It also improves multilevel isolation
> by reducing the ability of an attacker to use side channels with
> specific code. These restrictions can natively be enforced for ELF
> binaries (with the noexec mount option) but require this kernel
> extension to properly handle scripts (e.g., Python, Perl).
>
> Add a new sysctl kernel.yama.open_mayexec_enforce to control this
> behavior. A following patch adds documentation.
>
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
> Reviewed-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
> ---
[...]
> +/**
> + * yama_inode_permission - check O_MAYEXEC permission before accessing an inode
> + * @inode: inode structure to check
> + * @mask: permission mask
> + *
> + * Return 0 if access is permitted, -EACCES otherwise.
> + */
> +int yama_inode_permission(struct inode *inode, int mask)
This should be static, no?
> +{
> + if (!(mask & MAY_OPENEXEC))
> + return 0;
> + /*
> + * Match regular files and directories to make it easier to
> + * modify script interpreters.
> + */
> + if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode))
> + return 0;
So files are subject to checks, but loading code from things like
sockets is always fine?
> + if ((open_mayexec_enforce & YAMA_OMAYEXEC_ENFORCE_MOUNT) &&
> + !(mask & MAY_EXECMOUNT))
> + return -EACCES;
> +
> + /*
> + * May prefer acl_permission_check() instead of generic_permission(),
> + * to not be bypassable with CAP_DAC_READ_SEARCH.
> + */
> + if (open_mayexec_enforce & YAMA_OMAYEXEC_ENFORCE_FILE)
> + return generic_permission(inode, MAY_EXEC);
> +
> + return 0;
> +}
> +
> static struct security_hook_list yama_hooks[] __lsm_ro_after_init = {
> + LSM_HOOK_INIT(inode_permission, yama_inode_permission),
> LSM_HOOK_INIT(ptrace_access_check, yama_ptrace_access_check),
> LSM_HOOK_INIT(ptrace_traceme, yama_ptrace_traceme),
> LSM_HOOK_INIT(task_prctl, yama_task_prctl),
> @@ -447,6 +489,37 @@ static int yama_dointvec_minmax(struct ctl_table *table, int write,
> return proc_dointvec_minmax(&table_copy, write, buffer, lenp, ppos);
> }
>
> +static int yama_dointvec_bitmask_macadmin(struct ctl_table *table, int write,
> + void __user *buffer, size_t *lenp,
> + loff_t *ppos)
> +{
> + int error;
> +
> + if (write) {
> + struct ctl_table table_copy;
> + int tmp_mayexec_enforce;
> +
> + if (!capable(CAP_MAC_ADMIN))
> + return -EPERM;
Don't put capable() checks in sysctls, it doesn't work.
^ permalink raw reply
* Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Mickaël Salaün @ 2018-12-12 17:09 UTC (permalink / raw)
To: Jan Kara, Mickaël Salaün
Cc: linux-kernel, Al Viro, James Morris, Jonathan Corbet, Kees Cook,
Matthew Garrett, Michael Kerrisk, Mimi Zohar,
Philippe Trébuchet, Shuah Khan, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel, sgrubb, Matthew Bobrowski
In-Reply-To: <20181212144306.GA19945@quack2.suse.cz>
Le 12/12/2018 à 15:43, Jan Kara a écrit :
> On Wed 12-12-18 09:17:08, Mickaël Salaün wrote:
>> When the O_MAYEXEC flag is passed, sys_open() may be subject to
>> additional restrictions depending on a security policy implemented by an
>> LSM through the inode_permission hook.
>>
>> The underlying idea is to be able to restrict scripts interpretation
>> according to a policy defined by the system administrator. For this to
>> be possible, script interpreters must use the O_MAYEXEC flag
>> appropriately. To be fully effective, these interpreters also need to
>> handle the other ways to execute code (for which the kernel can't help):
>> command line parameters (e.g., option -e for Perl), module loading
>> (e.g., option -m for Python), stdin, file sourcing, environment
>> variables, configuration files... According to the threat model, it may
>> be acceptable to allow some script interpreters (e.g. Bash) to interpret
>> commands from stdin, may it be a TTY or a pipe, because it may not be
>> enough to (directly) perform syscalls.
>>
>> A simple security policy implementation is available in a following
>> patch for Yama.
>>
>> This is an updated subset of the patch initially written by Vincent
>> Strubel for CLIP OS:
>> https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch
>> This patch has been used for more than 10 years with customized script
>> interpreters. Some examples can be found here:
>> https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
>>
>> Signed-off-by: Mickaël Salaün <mic@digikod.net>
>> Signed-off-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
>> Signed-off-by: Vincent Strubel <vincent.strubel@ssi.gouv.fr>
>> Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
>> Cc: Al Viro <viro@zeniv.linux.org.uk>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
>
> ...
>
>> diff --git a/fs/open.c b/fs/open.c
>> index 0285ce7dbd51..75479b79a58f 100644
>> --- a/fs/open.c
>> +++ b/fs/open.c
>> @@ -974,6 +974,10 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o
>> if (flags & O_APPEND)
>> acc_mode |= MAY_APPEND;
>>
>> + /* Check execution permissions on open. */
>> + if (flags & O_MAYEXEC)
>> + acc_mode |= MAY_OPENEXEC;
>> +
>> op->acc_mode = acc_mode;
>>
>> op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN;
>
> I don't feel experienced enough in security to tell whether we want this
> functionality or not. But if we do this, shouldn't we also set FMODE_EXEC
> on the resulting struct file? That way also security_file_open() can be
> used to arbitrate such executable opens and in particular
> fanotify permission event FAN_OPEN_EXEC will get properly generated which I
> guess is desirable (support for it is sitting in my tree waiting for the
> merge window) - adding some audit people involved in FAN_OPEN_EXEC to
> CC. Just an idea...
Indeed, it may be useful for other LSM.
Mickaël
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
From: Mickaël Salaün @ 2018-12-12 17:01 UTC (permalink / raw)
To: Jordan Glover, Mickaël Salaün
Cc: linux-kernel@vger.kernel.org, Al Viro, James Morris,
Jonathan Corbet, Kees Cook, Matthew Garrett, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Shuah Khan,
Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org
In-Reply-To: <ML-sxPRwNNExkZHkXghYN7e3VrhuZXYLjFv-aniX8qbjcde2GfHMBaI4B3A7IoUEfycQcWCPuxATkYHOz--FqMjH1KRwxMxBCb6Q-1IsKTM=@protonmail.ch>
Le 12/12/2018 à 17:29, Jordan Glover a écrit :
> On Wednesday, December 12, 2018 9:17 AM, Mickaël Salaün <mic@digikod.net> wrote:
>
>> Hi,
>>
>> The goal of this patch series is to control script interpretation. A
>> new O_MAYEXEC flag used by sys_open() is added to enable userland script
>> interpreter to delegate to the kernel (and thus the system security
>> policy) the permission to interpret scripts or other files containing
>> what can be seen as commands.
>>
>> The security policy is the responsibility of an LSM. A basic
>> system-wide policy is implemented with Yama and configurable through a
>> sysctl.
>>
>> The initial idea come from CLIP OS and the original implementation has
>> been used for more than 10 years:
>> https://github.com/clipos-archive/clipos4_doc
>>
>> An introduction to O_MAYEXEC was given at the Linux Security Summit
>> Europe 2018 - Linux Kernel Security Contributions by ANSSI:
>> https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s
>> The "write xor execute" principle was explained at Kernel Recipes 2018 -
>> CLIP OS: a defense-in-depth OS:
>> https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s
>>
>> This patch series can be applied on top of v4.20-rc6. This can be
>> tested with CONFIG_SECURITY_YAMA. I would really appreciate
>> constructive comments on this RFC.
>>
>> Regards,
>>
>
> Are various interpreters upstreams interested in adding support
> for O_MAYEXEC if it land in kernel? Did you contacted them about this?
I think the first step is to be OK on the kernel side. We will then be
able to help upstream interpreters implement this feature. It should be
OK because the behavior doesn't change by default, i.e. if the sysadmin
doesn't configure (and test) the whole system. Some examples of modified
interpreters can be found at
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
.
Mickaël
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox