Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
On 05/08/2019 01:55, Andy Lutomirski wrote: > On Wed, Dec 12, 2018 at 6:43 AM Jan Kara wrote: >> >> 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 >>> Signed-off-by: Thibaut Sautereau >>> Signed-off-by: Vincent Strubel >>> Reviewed-by: Philippe Trébuchet >>> Cc: Al Viro >>> Cc: Kees Cook >>> Cc: Mickaël Salaün >> >> ... >> >>> 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... >> > > I would really like to land this patch. I'm fiddling with making > bpffs handle permissions intelligently, and the lack of a way to say > "hey, I want to open this bpf program so that I can run it" is > annoying. Are you OK with this series? What about Aleksa's work on openat2(), and Sean's work on SGX/noexec? Is it time to send a new patch series (with a dedicated LSM instead of Yama)?
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
On Wed, Dec 12, 2018 at 6:43 AM Jan Kara wrote: > > 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 > > Signed-off-by: Thibaut Sautereau > > Signed-off-by: Vincent Strubel > > Reviewed-by: Philippe Trébuchet > > Cc: Al Viro > > Cc: Kees Cook > > Cc: Mickaël Salaün > > ... > > > 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... > I would really like to land this patch. I'm fiddling with making bpffs handle permissions intelligently, and the lack of a way to say "hey, I want to open this bpf program so that I can run it" is annoying. --Andy
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
On 17/04/2019 12:01, Florian Weimer wrote: > * Steve Grubb: > >> On Tuesday, April 16, 2019 7:49:39 AM EDT Florian Weimer wrote: >>> * Steve Grubb: This flag that is being proposed means that you would have to patch all interpreters to use it. If you are sure that upstreams will accept that, why not just change the policy to interpreters shouldn't execute anything unless the execute bit is set? That is simpler and doesn't need a kernel change. And setting the execute bit is an auditable event. >>> >>> I think we need something like O_MAYEXEC so that security policies can >>> be enforced and noexec mounts can be detected. >> >> Application whitelisting can already today stop unknown software without >> needing O_MAYEXEC. Whitelisting may be a lot of thing (path/TPE, signed binaries…), but being able to handle this with a global system configuration (instead of app-specific hardcoded configuration) is a good idea. ;) > > I'm somewhat interested in using this to add a proper check for > executability to explicit dynamic loader invocations. In other words, > this > > /lib64/ld-linux-x86-64.so.2 /path/to/noexec/fs/program > > should refuse to run the program if the program is located on a file > system mounted with the noexec attribute. What if a sysadmin need to do this on an executable mount point? Being able to enforce a security policy according to a configuration may fit to much more use cases. > >> The problem is that passing O_MAYEXEC is opt-in. You can use ptrace/seccomp/ >> bpf/LD_PRELOAD/LD_AUDIT to remove that bit from an otherwise normal program. >> This does not require privs to do so. > > That doesn't really help with the above. Right, ptrace/LD_PRELOAD and so on must be addressed by something else than only O_MAYEXEC. > >> But let's consider that this comes to pass and every interpreter is >> updated and IMA can see the O_MAYEXEC flag. Attackers now simply pivot >> to running programs via stdin. It never touches disk and therefore >> nothing enforces security policy. This already is among the most >> common ways that malware runs today to evade detection. As my previous reply, use cases like stdin may be restricted as well. > > Are you referring to Windows malware using Powershell? > > I'm not sure this is applicable to Linux. We do not have much > behavioral monitoring anyway. > > Thanks, > Florian > -- Mickaël Salaün ANSSI/SDE/ST/LAM Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.r...@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.r...@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
On 15/04/2019 20:47, Steve Grubb wrote: > Hello, > > On Wednesday, December 12, 2018 9:43:06 AM EDT Jan Kara wrote: >> 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/f5cb330d >>> 6b684752e403b4e41b39f7004d88e561/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_MAYE >>> XEC >>> >>> Signed-off-by: Mickaël Salaün >>> Signed-off-by: Thibaut Sautereau >>> Signed-off-by: Vincent Strubel >>> Reviewed-by: Philippe Trébuchet >>> Cc: Al Viro >>> Cc: Kees Cook >>> Cc: Mickaël Salaün >> >> ... >> >>> 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... > > Late in replying. But I think it's important to have a deep look into the > issue. > > TL;DR - This is a gentle man's handshake. It won't _really_ solve the > problem. Thanks for your comments. You should find most answers in this thread: https://lore.kernel.org/lkml/20181212081712.32347-4-...@digikod.net/ The threat model targets persistent attacks. This O_MAYEXEC flag is not a silver bullet but it's a needed block to enforce a security policy on a trusted system. This means that every component executable on the system must be controlled, which means they may need some bit of customization. Today no userspace application use this flag (except in CLIP OS), but we need to first create a feature before it can be used. It is very important to have in mind that a system security policy need to have a (central) security manager, in this case the kernel thanks to Yama's policy (but it could be SELinux, IMA or any other LSM). The goal is not to give to the developer the job of defining a security policy for the *system*; this job is for the system administrator (or the distro). > > This flag that is being proposed means that you would have to patch all > interpreters to use it. If you are sure that upstreams will accept that, why > not just change the policy to interpreters shouldn't execute anything unless > the execute bit is set? That is simpler and doesn't need a kernel change. And > setting the execute bit is an auditable event. As said above, the definition of a the security policy is the job of the system administrator. Moreover, the security policy may be defined by the mount point restrictions (i.e. noexec) but it should be definable with something else (e.g. a SELinux or IMA policy which may be agnostic to the mount points). > > The bottom line is that any interpreter has to become a security policy > enforcement point whether by indicating it wants to execute by setting a flag > or by refusing to use a file without execute bit set. But this just moves the >
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
* Steve Grubb: > On Tuesday, April 16, 2019 7:49:39 AM EDT Florian Weimer wrote: >> * Steve Grubb: >> > This flag that is being proposed means that you would have to patch all >> > interpreters to use it. If you are sure that upstreams will accept that, >> > why not just change the policy to interpreters shouldn't execute >> > anything unless the execute bit is set? That is simpler and doesn't need >> > a kernel change. And setting the execute bit is an auditable event. >> >> I think we need something like O_MAYEXEC so that security policies can >> be enforced and noexec mounts can be detected. > > Application whitelisting can already today stop unknown software without > needing O_MAYEXEC. I'm somewhat interested in using this to add a proper check for executability to explicit dynamic loader invocations. In other words, this /lib64/ld-linux-x86-64.so.2 /path/to/noexec/fs/program should refuse to run the program if the program is located on a file system mounted with the noexec attribute. > The problem is that passing O_MAYEXEC is opt-in. You can use ptrace/seccomp/ > bpf/LD_PRELOAD/LD_AUDIT to remove that bit from an otherwise normal program. > This does not require privs to do so. That doesn't really help with the above. > But let's consider that this comes to pass and every interpreter is > updated and IMA can see the O_MAYEXEC flag. Attackers now simply pivot > to running programs via stdin. It never touches disk and therefore > nothing enforces security policy. This already is among the most > common ways that malware runs today to evade detection. Are you referring to Windows malware using Powershell? I'm not sure this is applicable to Linux. We do not have much behavioral monitoring anyway. Thanks, Florian
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
On Tuesday, April 16, 2019 7:49:39 AM EDT Florian Weimer wrote: > * Steve Grubb: > > This flag that is being proposed means that you would have to patch all > > interpreters to use it. If you are sure that upstreams will accept that, > > why not just change the policy to interpreters shouldn't execute > > anything unless the execute bit is set? That is simpler and doesn't need > > a kernel change. And setting the execute bit is an auditable event. > > I think we need something like O_MAYEXEC so that security policies can > be enforced and noexec mounts can be detected. Application whitelisting can already today stop unknown software without needing O_MAYEXEC. > I don't think it's a good idea to do this in userspace, especially the > latter. The problem is that passing O_MAYEXEC is opt-in. You can use ptrace/seccomp/ bpf/LD_PRELOAD/LD_AUDIT to remove that bit from an otherwise normal program. This does not require privs to do so. But let's consider that this comes to pass and every interpreter is updated and IMA can see the O_MAYEXEC flag. Attackers now simply pivot to running programs via stdin. It never touches disk and therefore nothing enforces security policy. This already is among the most common ways that malware runs today to evade detection. -Steve
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
* Steve Grubb: > This flag that is being proposed means that you would have to patch all > interpreters to use it. If you are sure that upstreams will accept that, why > not just change the policy to interpreters shouldn't execute anything unless > the execute bit is set? That is simpler and doesn't need a kernel change. And > setting the execute bit is an auditable event. I think we need something like O_MAYEXEC so that security policies can be enforced and noexec mounts can be detected. I don't think it's a good idea to do this in userspace, especially the latter. Thanks, Florian
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
Hello, On Wednesday, December 12, 2018 9:43:06 AM EDT Jan Kara wrote: > 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/f5cb330d > > 6b684752e403b4e41b39f7004d88e561/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_MAYE > > XEC > > > > Signed-off-by: Mickaël Salaün > > Signed-off-by: Thibaut Sautereau > > Signed-off-by: Vincent Strubel > > Reviewed-by: Philippe Trébuchet > > Cc: Al Viro > > Cc: Kees Cook > > Cc: Mickaël Salaün > > ... > > > 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... Late in replying. But I think it's important to have a deep look into the issue. TL;DR - This is a gentle man's handshake. It won't _really_ solve the problem. This flag that is being proposed means that you would have to patch all interpreters to use it. If you are sure that upstreams will accept that, why not just change the policy to interpreters shouldn't execute anything unless the execute bit is set? That is simpler and doesn't need a kernel change. And setting the execute bit is an auditable event. The bottom line is that any interpreter has to become a security policy enforcement point whether by indicating it wants to execute by setting a flag or by refusing to use a file without execute bit set. But this just moves the problem to one that is harder to fix. Why in the world does any programming language allow programs to be loaded via stdin? It is possible to wget a program and pipe it into python which subsequently pulls down an ELF shared object and runs it all without touching disk via memfd_create (e.g. SnakeEater). This is all direct to memory execution. And direct to memory bypasses anti-virus, selinux, IMA, application whitelisting, and other integrity schemes. So, to fix this problem, you really need to not allow any programs to load via stdin so that everything that executes has to touch disk. This way you can get a fanotify event and see the application and vote yes/no on allowing it. And this will be particularly harder with the memfd_create fix for the runc container breakout. Prior to that, there were very few uses of that system call. Now it may be very common which means finding malicious use just got harder to spot. But assuming these problems got fixed, then we have yet another place to look. Many interpreters allow you to specify a command to run via arguments. Some have a small buffer and some allow lengthy programs to be entered as an argument. One strategy might be that an attacker can bootstrap a lengthier program across the network. Python for
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
On 13/12/2018 10:47, Matthew Bobrowski wrote: > 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 >>> Signed-off-by: Thibaut Sautereau >>> Signed-off-by: Vincent Strubel >>> Reviewed-by: Philippe Trébuchet >>> Cc: Al Viro >>> Cc: Kees Cook >>> Cc: Mickaël Salaün >> >> ... >> >>> 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? That's correct. The kernel knows the semantic but the enforcement is delegated to an LSM and its policy. > 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. OK, I will add it in the next patch series (for the new FAN_OPEN_EXEC support).
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
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 > > Signed-off-by: Thibaut Sautereau > > Signed-off-by: Vincent Strubel > > Reviewed-by: Philippe Trébuchet > > Cc: Al Viro > > Cc: Kees Cook > > Cc: Mickaël Salaün > > ... > > > 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
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
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
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
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 >> Signed-off-by: Thibaut Sautereau >> Signed-off-by: Vincent Strubel >> Reviewed-by: Philippe Trébuchet >> Cc: Al Viro >> Cc: Kees Cook >> Cc: Mickaël Salaün > > ... > >> 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
Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
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 > Signed-off-by: Thibaut Sautereau > Signed-off-by: Vincent Strubel > Reviewed-by: Philippe Trébuchet > Cc: Al Viro > Cc: Kees Cook > Cc: Mickaël Salaün ... > 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... Honza -- Jan Kara SUSE Labs, CR
