Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Casey Schaufler]

On 7/13/2017 12:51 PM, Serge E. Hallyn wrote:
> Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
>> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
>> The question is really from a security perspective which is better?
>>  Obviously, as v2 of the patch set changed from using pathnames to
>> inodes, it's pretty clear that I think inodes would be better.  Kees,
>> Serge, Casey any comments?
> Yes, inode seems clearly better.  Paths are too easily worked around.

An inode identifies the object, while a pathname identifies the intent.
Using the inode will be easier to code and easier to model. Using the
pathname will be much more likely to reflect what the human means to
accomplish, provided all the idiosyncrasies of the Linux filesystem
namespace are taken into account. Ever since the link count on an inode
was allowed to exceed 1* this has been difficult to accomplish.


* The link count has always been allowed to exceed 1. Then there
  are symlinks, mount points, overlay filesystems and all manner
  of other slick features that make the filesystem namespace
  difficult to deal with from the security standpoint.

> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Casey Schaufler]

On 7/13/2017 12:51 PM, Serge E. Hallyn wrote:
> Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
>> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
>> The question is really from a security perspective which is better?
>>  Obviously, as v2 of the patch set changed from using pathnames to
>> inodes, it's pretty clear that I think inodes would be better.  Kees,
>> Serge, Casey any comments?
> Yes, inode seems clearly better.  Paths are too easily worked around.

An inode identifies the object, while a pathname identifies the intent.
Using the inode will be easier to code and easier to model. Using the
pathname will be much more likely to reflect what the human means to
accomplish, provided all the idiosyncrasies of the Linux filesystem
namespace are taken into account. Ever since the link count on an inode
was allowed to exceed 1* this has been difficult to accomplish.


* The link count has always been allowed to exceed 1. Then there
  are symlinks, mount points, overlay filesystems and all manner
  of other slick features that make the filesystem namespace
  difficult to deal with from the security standpoint.

> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Matt Brown]

On 7/13/17 3:51 PM, Serge E. Hallyn wrote:
> Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
>> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
>> The question is really from a security perspective which is better?
>>  Obviously, as v2 of the patch set changed from using pathnames to
>> inodes, it's pretty clear that I think inodes would be better.  Kees,
>> Serge, Casey any comments?
> 
> Yes, inode seems clearly better.  Paths are too easily worked around.
> 

Sounds good. Do we think a rb_tree would be better than a list to store
the inodes in?

Matt

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Matt Brown]

On 7/13/17 3:51 PM, Serge E. Hallyn wrote:
> Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
>> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
>> The question is really from a security perspective which is better?
>>  Obviously, as v2 of the patch set changed from using pathnames to
>> inodes, it's pretty clear that I think inodes would be better.  Kees,
>> Serge, Casey any comments?
> 
> Yes, inode seems clearly better.  Paths are too easily worked around.
> 

Sounds good. Do we think a rb_tree would be better than a list to store
the inodes in?

Matt

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Serge E. Hallyn]

Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
> The question is really from a security perspective which is better?
>  Obviously, as v2 of the patch set changed from using pathnames to
> inodes, it's pretty clear that I think inodes would be better.  Kees,
> Serge, Casey any comments?

Yes, inode seems clearly better.  Paths are too easily worked around.

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Serge E. Hallyn]

Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
> The question is really from a security perspective which is better?
>  Obviously, as v2 of the patch set changed from using pathnames to
> inodes, it's pretty clear that I think inodes would be better.  Kees,
> Serge, Casey any comments?

Yes, inode seems clearly better.  Paths are too easily worked around.

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mimi Zohar]

On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
> On 7/11/17 3:31 PM, Mimi Zohar wrote:
> > On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote:
> > 
> >> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
> >> releasing a version 3 soon. I have also added securityfs support to
> >> shebang that will allow users to update the interpreter list at run
> >> time. This allows for user's to configure TPE/Shebang without any
> >> xattrs. For a preview of my version 3 you can check out my dev tree
> >> here:
> >> https://github.com/nmatt0/linux-security/tree/tpe/security/tpe
> >>
> >> Note: that git tree is WIP and may not have all of the attribution and
> >> documentation needed.
> > 
> > You'll want to detect when an interpreter is deleted or renamed.  I
> > would define security_inode_rename, security_path_rename,
> > security_inode_unlink and security_path_unlink hooks.
> > 
> > "rename" could be an indication that the existing interpreter is being
> > updated. "unlink" indicates that the interpreter has been deleted.  At
> > either of these points, you'll want to start checking for the creation
> > of a new file with the expected pathname.
> > 
> > Mimi
> > 
> 
> Would it be better just to check for paths rather than inodes?

Below is a simple example on my laptop of the same inode with
different path names.  In this case, a list of pathnames would be
double the number of inodes.  I'm not sure from a performance
perspective if this really matters, or if doing string compares
matters.  We're not talking about thousands or even hundreds of files,
though this is on the LSM bprm check hook.

The question is really from a security perspective which is better?
 Obviously, as v2 of the patch set changed from using pathnames to
inodes, it's pretty clear that I think inodes would be better.  Kees,
Serge, Casey any comments?

example:
$ rpm -qf /usr/bin/bash
bash-4.3.42-7.fc24.x86_64

$ rpm -q --dump bash | grep \/bin\/bash
/usr/bin/bash 1071984 1475233750
84c7d10de5f9c729f9d60e95bc97197a5e029a14e07820bc45ad309da91703f9
0100755 root root 0 0 0 X
/usr/bin/bashbug 10 1475233749

0120777 root root 0 0 0 bashbug-64
/usr/bin/bashbug-64 7110 1475233745
0dd706d221569a7966f0246fcb40dd7f3bff4550c4ad0ee70ae8b0c6bc350157
0100755 root root 0 0 0 X

$ stat /bin/bash
  File: '/bin/bash'
  Size: 1071984     Blocks: 2104   IO Block: 4096   regular
file
Device: 804h/2052d  Inode: 1180420 Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid:
(0/root)
Context: system_u:object_r:shell_exec_t:s0
Access: 2017-07-12 21:56:28.125594261 -0400
Modify: 2016-09-30 07:09:10.0 -0400
Change: 2017-01-25 10:10:18.784719749 -0500
 Birth: -

$ stat /usr/bin/bash
  File: '/usr/bin/bash'
  Size: 1071984     Blocks: 2104   IO Block: 4096   regular
file
Device: 804h/2052d  Inode: 1180420 Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid:
(0/root)
Context: system_u:object_r:shell_exec_t:s0
Access: 2017-07-12 21:56:28.125594261 -0400
Modify: 2016-09-30 07:09:10.0 -0400
Change: 2017-01-25 10:10:18.784719749 -0500
 Birth: -

$ ls -lat / | grep bin
lrwxrwxrwx.   1 root root 7 Feb  3  2016 bin -> usr/bin
lrwxrwxrwx.   1 root root 8 Feb  3  2016 sbin -> usr/sbin

Mimi

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mimi Zohar]

On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote:
> On 7/11/17 3:31 PM, Mimi Zohar wrote:
> > On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote:
> > 
> >> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
> >> releasing a version 3 soon. I have also added securityfs support to
> >> shebang that will allow users to update the interpreter list at run
> >> time. This allows for user's to configure TPE/Shebang without any
> >> xattrs. For a preview of my version 3 you can check out my dev tree
> >> here:
> >> https://github.com/nmatt0/linux-security/tree/tpe/security/tpe
> >>
> >> Note: that git tree is WIP and may not have all of the attribution and
> >> documentation needed.
> > 
> > You'll want to detect when an interpreter is deleted or renamed.  I
> > would define security_inode_rename, security_path_rename,
> > security_inode_unlink and security_path_unlink hooks.
> > 
> > "rename" could be an indication that the existing interpreter is being
> > updated. "unlink" indicates that the interpreter has been deleted.  At
> > either of these points, you'll want to start checking for the creation
> > of a new file with the expected pathname.
> > 
> > Mimi
> > 
> 
> Would it be better just to check for paths rather than inodes?

Below is a simple example on my laptop of the same inode with
different path names.  In this case, a list of pathnames would be
double the number of inodes.  I'm not sure from a performance
perspective if this really matters, or if doing string compares
matters.  We're not talking about thousands or even hundreds of files,
though this is on the LSM bprm check hook.

The question is really from a security perspective which is better?
 Obviously, as v2 of the patch set changed from using pathnames to
inodes, it's pretty clear that I think inodes would be better.  Kees,
Serge, Casey any comments?

example:
$ rpm -qf /usr/bin/bash
bash-4.3.42-7.fc24.x86_64

$ rpm -q --dump bash | grep \/bin\/bash
/usr/bin/bash 1071984 1475233750
84c7d10de5f9c729f9d60e95bc97197a5e029a14e07820bc45ad309da91703f9
0100755 root root 0 0 0 X
/usr/bin/bashbug 10 1475233749

0120777 root root 0 0 0 bashbug-64
/usr/bin/bashbug-64 7110 1475233745
0dd706d221569a7966f0246fcb40dd7f3bff4550c4ad0ee70ae8b0c6bc350157
0100755 root root 0 0 0 X

$ stat /bin/bash
  File: '/bin/bash'
  Size: 1071984     Blocks: 2104   IO Block: 4096   regular
file
Device: 804h/2052d  Inode: 1180420 Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid:
(0/root)
Context: system_u:object_r:shell_exec_t:s0
Access: 2017-07-12 21:56:28.125594261 -0400
Modify: 2016-09-30 07:09:10.0 -0400
Change: 2017-01-25 10:10:18.784719749 -0500
 Birth: -

$ stat /usr/bin/bash
  File: '/usr/bin/bash'
  Size: 1071984     Blocks: 2104   IO Block: 4096   regular
file
Device: 804h/2052d  Inode: 1180420 Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid:
(0/root)
Context: system_u:object_r:shell_exec_t:s0
Access: 2017-07-12 21:56:28.125594261 -0400
Modify: 2016-09-30 07:09:10.0 -0400
Change: 2017-01-25 10:10:18.784719749 -0500
 Birth: -

$ ls -lat / | grep bin
lrwxrwxrwx.   1 root root 7 Feb  3  2016 bin -> usr/bin
lrwxrwxrwx.   1 root root 8 Feb  3  2016 sbin -> usr/sbin

Mimi

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Matt Brown]

On 7/11/17 3:31 PM, Mimi Zohar wrote:
> On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote:
> 
>> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
>> releasing a version 3 soon. I have also added securityfs support to
>> shebang that will allow users to update the interpreter list at run
>> time. This allows for user's to configure TPE/Shebang without any
>> xattrs. For a preview of my version 3 you can check out my dev tree
>> here:
>> https://github.com/nmatt0/linux-security/tree/tpe/security/tpe
>>
>> Note: that git tree is WIP and may not have all of the attribution and
>> documentation needed.
> 
> You'll want to detect when an interpreter is deleted or renamed.  I
> would define security_inode_rename, security_path_rename,
> security_inode_unlink and security_path_unlink hooks.
> 
> "rename" could be an indication that the existing interpreter is being
> updated. "unlink" indicates that the interpreter has been deleted.  At
> either of these points, you'll want to start checking for the creation
> of a new file with the expected pathname.
> 
> Mimi
> 

Would it be better just to check for paths rather than inodes?

Matt

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Matt Brown]

On 7/11/17 3:31 PM, Mimi Zohar wrote:
> On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote:
> 
>> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
>> releasing a version 3 soon. I have also added securityfs support to
>> shebang that will allow users to update the interpreter list at run
>> time. This allows for user's to configure TPE/Shebang without any
>> xattrs. For a preview of my version 3 you can check out my dev tree
>> here:
>> https://github.com/nmatt0/linux-security/tree/tpe/security/tpe
>>
>> Note: that git tree is WIP and may not have all of the attribution and
>> documentation needed.
> 
> You'll want to detect when an interpreter is deleted or renamed.  I
> would define security_inode_rename, security_path_rename,
> security_inode_unlink and security_path_unlink hooks.
> 
> "rename" could be an indication that the existing interpreter is being
> updated. "unlink" indicates that the interpreter has been deleted.  At
> either of these points, you'll want to start checking for the creation
> of a new file with the expected pathname.
> 
> Mimi
> 

Would it be better just to check for paths rather than inodes?

Matt

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mimi Zohar]

On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote:

> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
> releasing a version 3 soon. I have also added securityfs support to
> shebang that will allow users to update the interpreter list at run
> time. This allows for user's to configure TPE/Shebang without any
> xattrs. For a preview of my version 3 you can check out my dev tree
> here:
> https://github.com/nmatt0/linux-security/tree/tpe/security/tpe
> 
> Note: that git tree is WIP and may not have all of the attribution and
> documentation needed.

You'll want to detect when an interpreter is deleted or renamed.  I
would define security_inode_rename, security_path_rename,
security_inode_unlink and security_path_unlink hooks.

"rename" could be an indication that the existing interpreter is being
updated. "unlink" indicates that the interpreter has been deleted.  At
either of these points, you'll want to start checking for the creation
of a new file with the expected pathname.

Mimi

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mimi Zohar]

On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote:

> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
> releasing a version 3 soon. I have also added securityfs support to
> shebang that will allow users to update the interpreter list at run
> time. This allows for user's to configure TPE/Shebang without any
> xattrs. For a preview of my version 3 you can check out my dev tree
> here:
> https://github.com/nmatt0/linux-security/tree/tpe/security/tpe
> 
> Note: that git tree is WIP and may not have all of the attribution and
> documentation needed.

You'll want to detect when an interpreter is deleted or renamed.  I
would define security_inode_rename, security_path_rename,
security_inode_unlink and security_path_unlink hooks.

"rename" could be an indication that the existing interpreter is being
updated. "unlink" indicates that the interpreter has been deleted.  At
either of these points, you'll want to start checking for the creation
of a new file with the expected pathname.

Mimi

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Matt Brown]

On 7/11/17 12:58 PM, Salvatore Mesoraca wrote:
> 2017-07-11 1:40 GMT+02:00 Mickaël Salaün :
>>
>> On 10/07/2017 09:59, Salvatore Mesoraca wrote:
>>> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
 Hi,

 I think it make sense to merge the W^X features with the TPE/shebang LSM
 [1].

 Regards,
  Mickaël

 [1]
 https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net
>>>
>>> Hi,
>>> Can you elaborate why it would be an advantage to have those features 
>>> merged?
>>> They seem quite unrelated.
>>> Also, they work in rather different ways in respect to how they are 
>>> configured.
>>> I'm not sure what would be a reasonable way to merge them.
>>> Thank you for your comment,
>>>
>>> Salvatore
>>>
>>
>> The aim of the Trusted Path Execution is to constraint calls to execve
>> (e.g. forbid an user to execute his own binaries, i.e. apply a W^X
>> security policy). This should handle binaries and could handle scripts
>> too [1]. However, there is always a way for a process to mmap/mprotect
>> arbitrary data and make it executable, be it intentional or not. PaX and
>> the W^X part of your LSM can handle this, or make exceptions by marking
>> a file with dedicated xattr values. This kind of exception fit well with
>> TPE to get a more hardened executable security policy (e.g. forbid an
>> user to execute his own binaries or to mmap arbitrary executable code).
>> Moreover, TPE could handle some part of its configuration from some
>> xattr values (e.g. allow scripts/interpreters, a whitelist of
>> environment variables, additional memory restrictions…) as you do with
>> SARA thanks to your tools.
> 
> I understand your point. They complement each other in some sense.
> On the other hand, I'm still worried about the suitability of merging,
> under the same LSM, two features that are managed in two
> completely different ways.
> IMHO, if they have to be merged, they should be "integrated".
> As I see it, there are only 3 possible solutions to this problem:
> 1 - SARA gives up its configuration mechanics and starts using xattrs
> 2 - TPE/shebang gives up xattrs and starts using SARA-style configurations
> 3 - SARA adds xattrs support to its quiver *and* TPE/shebang adds SARA-style
>  configuration support.
> 
> The solution number 1 is the one I'm less inclined to, as you can imagine.
> I'm in favor of solutions 2 and 3, but of course we need to know Mimi Zohar 
> and
> Matt Brown opinion on this matter.
> If we can find a consensus on the best way to merge them, I'm not against
> the merge.
> Anyway, these LSMs are stackable and they can be used together even if they
> don't get merged. So I think that merging them is not a "must".
> 
> Salvatore
> 

I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
releasing a version 3 soon. I have also added securityfs support to
shebang that will allow users to update the interpreter list at run
time. This allows for user's to configure TPE/Shebang without any
xattrs. For a preview of my version 3 you can check out my dev tree
here:
https://github.com/nmatt0/linux-security/tree/tpe/security/tpe

Note: that git tree is WIP and may not have all of the attribution and
documentation needed.

Matt Brown

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Matt Brown]

On 7/11/17 12:58 PM, Salvatore Mesoraca wrote:
> 2017-07-11 1:40 GMT+02:00 Mickaël Salaün :
>>
>> On 10/07/2017 09:59, Salvatore Mesoraca wrote:
>>> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
 Hi,

 I think it make sense to merge the W^X features with the TPE/shebang LSM
 [1].

 Regards,
  Mickaël

 [1]
 https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net
>>>
>>> Hi,
>>> Can you elaborate why it would be an advantage to have those features 
>>> merged?
>>> They seem quite unrelated.
>>> Also, they work in rather different ways in respect to how they are 
>>> configured.
>>> I'm not sure what would be a reasonable way to merge them.
>>> Thank you for your comment,
>>>
>>> Salvatore
>>>
>>
>> The aim of the Trusted Path Execution is to constraint calls to execve
>> (e.g. forbid an user to execute his own binaries, i.e. apply a W^X
>> security policy). This should handle binaries and could handle scripts
>> too [1]. However, there is always a way for a process to mmap/mprotect
>> arbitrary data and make it executable, be it intentional or not. PaX and
>> the W^X part of your LSM can handle this, or make exceptions by marking
>> a file with dedicated xattr values. This kind of exception fit well with
>> TPE to get a more hardened executable security policy (e.g. forbid an
>> user to execute his own binaries or to mmap arbitrary executable code).
>> Moreover, TPE could handle some part of its configuration from some
>> xattr values (e.g. allow scripts/interpreters, a whitelist of
>> environment variables, additional memory restrictions…) as you do with
>> SARA thanks to your tools.
> 
> I understand your point. They complement each other in some sense.
> On the other hand, I'm still worried about the suitability of merging,
> under the same LSM, two features that are managed in two
> completely different ways.
> IMHO, if they have to be merged, they should be "integrated".
> As I see it, there are only 3 possible solutions to this problem:
> 1 - SARA gives up its configuration mechanics and starts using xattrs
> 2 - TPE/shebang gives up xattrs and starts using SARA-style configurations
> 3 - SARA adds xattrs support to its quiver *and* TPE/shebang adds SARA-style
>  configuration support.
> 
> The solution number 1 is the one I'm less inclined to, as you can imagine.
> I'm in favor of solutions 2 and 3, but of course we need to know Mimi Zohar 
> and
> Matt Brown opinion on this matter.
> If we can find a consensus on the best way to merge them, I'm not against
> the merge.
> Anyway, these LSMs are stackable and they can be used together even if they
> don't get merged. So I think that merging them is not a "must".
> 
> Salvatore
> 

I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
releasing a version 3 soon. I have also added securityfs support to
shebang that will allow users to update the interpreter list at run
time. This allows for user's to configure TPE/Shebang without any
xattrs. For a preview of my version 3 you can check out my dev tree
here:
https://github.com/nmatt0/linux-security/tree/tpe/security/tpe

Note: that git tree is WIP and may not have all of the attribution and
documentation needed.

Matt Brown

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Salvatore Mesoraca]

2017-07-11 1:40 GMT+02:00 Mickaël Salaün :
>
> On 10/07/2017 09:59, Salvatore Mesoraca wrote:
>> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
>>> Hi,
>>>
>>> I think it make sense to merge the W^X features with the TPE/shebang LSM
>>> [1].
>>>
>>> Regards,
>>>  Mickaël
>>>
>>> [1]
>>> https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net
>>
>> Hi,
>> Can you elaborate why it would be an advantage to have those features merged?
>> They seem quite unrelated.
>> Also, they work in rather different ways in respect to how they are 
>> configured.
>> I'm not sure what would be a reasonable way to merge them.
>> Thank you for your comment,
>>
>> Salvatore
>>
>
> The aim of the Trusted Path Execution is to constraint calls to execve
> (e.g. forbid an user to execute his own binaries, i.e. apply a W^X
> security policy). This should handle binaries and could handle scripts
> too [1]. However, there is always a way for a process to mmap/mprotect
> arbitrary data and make it executable, be it intentional or not. PaX and
> the W^X part of your LSM can handle this, or make exceptions by marking
> a file with dedicated xattr values. This kind of exception fit well with
> TPE to get a more hardened executable security policy (e.g. forbid an
> user to execute his own binaries or to mmap arbitrary executable code).
> Moreover, TPE could handle some part of its configuration from some
> xattr values (e.g. allow scripts/interpreters, a whitelist of
> environment variables, additional memory restrictions…) as you do with
> SARA thanks to your tools.

I understand your point. They complement each other in some sense.
On the other hand, I'm still worried about the suitability of merging,
under the same LSM, two features that are managed in two
completely different ways.
IMHO, if they have to be merged, they should be "integrated".
As I see it, there are only 3 possible solutions to this problem:
1 - SARA gives up its configuration mechanics and starts using xattrs
2 - TPE/shebang gives up xattrs and starts using SARA-style configurations
3 - SARA adds xattrs support to its quiver *and* TPE/shebang adds SARA-style
 configuration support.

The solution number 1 is the one I'm less inclined to, as you can imagine.
I'm in favor of solutions 2 and 3, but of course we need to know Mimi Zohar and
Matt Brown opinion on this matter.
If we can find a consensus on the best way to merge them, I'm not against
the merge.
Anyway, these LSMs are stackable and they can be used together even if they
don't get merged. So I think that merging them is not a "must".

Salvatore

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Salvatore Mesoraca]

2017-07-11 1:40 GMT+02:00 Mickaël Salaün :
>
> On 10/07/2017 09:59, Salvatore Mesoraca wrote:
>> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
>>> Hi,
>>>
>>> I think it make sense to merge the W^X features with the TPE/shebang LSM
>>> [1].
>>>
>>> Regards,
>>>  Mickaël
>>>
>>> [1]
>>> https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net
>>
>> Hi,
>> Can you elaborate why it would be an advantage to have those features merged?
>> They seem quite unrelated.
>> Also, they work in rather different ways in respect to how they are 
>> configured.
>> I'm not sure what would be a reasonable way to merge them.
>> Thank you for your comment,
>>
>> Salvatore
>>
>
> The aim of the Trusted Path Execution is to constraint calls to execve
> (e.g. forbid an user to execute his own binaries, i.e. apply a W^X
> security policy). This should handle binaries and could handle scripts
> too [1]. However, there is always a way for a process to mmap/mprotect
> arbitrary data and make it executable, be it intentional or not. PaX and
> the W^X part of your LSM can handle this, or make exceptions by marking
> a file with dedicated xattr values. This kind of exception fit well with
> TPE to get a more hardened executable security policy (e.g. forbid an
> user to execute his own binaries or to mmap arbitrary executable code).
> Moreover, TPE could handle some part of its configuration from some
> xattr values (e.g. allow scripts/interpreters, a whitelist of
> environment variables, additional memory restrictions…) as you do with
> SARA thanks to your tools.

I understand your point. They complement each other in some sense.
On the other hand, I'm still worried about the suitability of merging,
under the same LSM, two features that are managed in two
completely different ways.
IMHO, if they have to be merged, they should be "integrated".
As I see it, there are only 3 possible solutions to this problem:
1 - SARA gives up its configuration mechanics and starts using xattrs
2 - TPE/shebang gives up xattrs and starts using SARA-style configurations
3 - SARA adds xattrs support to its quiver *and* TPE/shebang adds SARA-style
 configuration support.

The solution number 1 is the one I'm less inclined to, as you can imagine.
I'm in favor of solutions 2 and 3, but of course we need to know Mimi Zohar and
Matt Brown opinion on this matter.
If we can find a consensus on the best way to merge them, I'm not against
the merge.
Anyway, these LSMs are stackable and they can be used together even if they
don't get merged. So I think that merging them is not a "must".

Salvatore

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mickaël Salaün]

On 10/07/2017 09:59, Salvatore Mesoraca wrote:
> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
>> Hi,
>>
>> I think it make sense to merge the W^X features with the TPE/shebang LSM
>> [1].
>>
>> Regards,
>>  Mickaël
>>
>> [1]
>> https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net
> 
> Hi,
> Can you elaborate why it would be an advantage to have those features merged?
> They seem quite unrelated.
> Also, they work in rather different ways in respect to how they are 
> configured.
> I'm not sure what would be a reasonable way to merge them.
> Thank you for your comment,
> 
> Salvatore
> 

The aim of the Trusted Path Execution is to constraint calls to execve
(e.g. forbid an user to execute his own binaries, i.e. apply a W^X
security policy). This should handle binaries and could handle scripts
too [1]. However, there is always a way for a process to mmap/mprotect
arbitrary data and make it executable, be it intentional or not. PaX and
the W^X part of your LSM can handle this, or make exceptions by marking
a file with dedicated xattr values. This kind of exception fit well with
TPE to get a more hardened executable security policy (e.g. forbid an
user to execute his own binaries or to mmap arbitrary executable code).
Moreover, TPE could handle some part of its configuration from some
xattr values (e.g. allow scripts/interpreters, a whitelist of
environment variables, additional memory restrictions…) as you do with
SARA thanks to your tools.

 Mickaël

[1]
https://lkml.kernel.org/r/25278a42-736e-0d3b-8c0a-7b2b05ed7...@digikod.net



signature.asc
Description: OpenPGP digital signature

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mickaël Salaün]

On 10/07/2017 09:59, Salvatore Mesoraca wrote:
> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
>> Hi,
>>
>> I think it make sense to merge the W^X features with the TPE/shebang LSM
>> [1].
>>
>> Regards,
>>  Mickaël
>>
>> [1]
>> https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net
> 
> Hi,
> Can you elaborate why it would be an advantage to have those features merged?
> They seem quite unrelated.
> Also, they work in rather different ways in respect to how they are 
> configured.
> I'm not sure what would be a reasonable way to merge them.
> Thank you for your comment,
> 
> Salvatore
> 

The aim of the Trusted Path Execution is to constraint calls to execve
(e.g. forbid an user to execute his own binaries, i.e. apply a W^X
security policy). This should handle binaries and could handle scripts
too [1]. However, there is always a way for a process to mmap/mprotect
arbitrary data and make it executable, be it intentional or not. PaX and
the W^X part of your LSM can handle this, or make exceptions by marking
a file with dedicated xattr values. This kind of exception fit well with
TPE to get a more hardened executable security policy (e.g. forbid an
user to execute his own binaries or to mmap arbitrary executable code).
Moreover, TPE could handle some part of its configuration from some
xattr values (e.g. allow scripts/interpreters, a whitelist of
environment variables, additional memory restrictions…) as you do with
SARA thanks to your tools.

 Mickaël

[1]
https://lkml.kernel.org/r/25278a42-736e-0d3b-8c0a-7b2b05ed7...@digikod.net



signature.asc
Description: OpenPGP digital signature

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Salvatore Mesoraca]

2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
> Hi,
>
> I think it make sense to merge the W^X features with the TPE/shebang LSM
> [1].
>
> Regards,
>  Mickaël
>
> [1]
> https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net

Hi,
Can you elaborate why it would be an advantage to have those features merged?
They seem quite unrelated.
Also, they work in rather different ways in respect to how they are configured.
I'm not sure what would be a reasonable way to merge them.
Thank you for your comment,

Salvatore

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Salvatore Mesoraca]

2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
> Hi,
>
> I think it make sense to merge the W^X features with the TPE/shebang LSM
> [1].
>
> Regards,
>  Mickaël
>
> [1]
> https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net

Hi,
Can you elaborate why it would be an advantage to have those features merged?
They seem quite unrelated.
Also, they work in rather different ways in respect to how they are configured.
I'm not sure what would be a reasonable way to merge them.
Thank you for your comment,

Salvatore

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mickaël Salaün]

Hi,

I think it make sense to merge the W^X features with the TPE/shebang LSM
[1].

Regards,
 Mickaël

[1]
https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net

On 12/06/2017 18:56, Salvatore Mesoraca wrote:
> S.A.R.A. (S.A.R.A. is Another Recursive Acronym) is a stacked Linux
> Security Module that aims to collect heterogeneous security measures,
> providing a common interface to manage them.
> It can be useful to allow minor security features to use advanced
> management options, like user-space configuration files and tools, without
> too much overhead.
> Some submodules that use this framework are also introduced.
> The code is quite long, I apologize for this. Thank you in advance to
> anyone who will take the time to review this patchset.
> 
> S.A.R.A. is meant to be stacked but it needs cred blobs and the procattr
> interface, so I temporarily implemented those parts in a way that won't
> be acceptable for upstream, but it works for now. I know that there
> is some ongoing work to make cred blobs and procattr stackable, as soon
> as the new interfaces will be available I'll reimplement the involved
> parts.
> At the moment I've been able to test it only on x86.
> 
> S.A.R.A. submodules introduced in this patchset are: USB Filtering and
> WX Protection.
> 
> The kernel-space part is complemented by its user-space counterpart:
> saractl [1].
> A test suite for WX Protection, called sara-test [2], is also available.
> 
> USB Filtering aims to provide a mechanism to decide which USB devices
> should be authorized to connect to the system and which shouldn't. The main
> goal is to narrow the attack surface for custom USB devices designed to
> exploit vulnerabilities found in some USB device drivers.
> Via configuration it's possible to allow or to deny authorization, based
> on one or more of: Vendor ID, Product ID, bus name and port number. There
> is also limited support for wildcards.
> Depending on the configuration, it can work both as a white list or as a
> black list.
> With the help of "saractl" it's also possible to completely disable new
> USB devices when the screen is "locked".
> The original idea is inspired by the Grsecurity "Deny USB" feature.
> 
> WX Protection aims to improve user-space programs security by applying:
> - W^X enforcement: program can't have a page of memory that is marked, at
>  the same time, writable and executable.
> - W!->X restriction: any page that could have been marked as writable in
>the past won't ever be allowed to be marked as
>executable.
> - Executable MMAP prevention: prevents the creation of new executable mmaps
> after the dynamic libraries have been loaded.
> All of the above features can be enabled or disabled both system wide
> or on a per executable basis through the use of configuration files managed
> by "saractl".
> It is important to note that some programs may have issues working with
> WX Protection. In particular:
> - W^X enforcement will cause problems to any programs that needs
>   memory pages mapped both as writable and executable at the same time e.g.
>   programs with executable stack markings in the PT_GNU_STACK segment.
> - W!->X restriction will cause problems to any program that
>   needs to generate executable code at run time or to modify executable
>   pages e.g. programs with a JIT compiler built-in or linked against a
>   non-PIC library.
> - Executable MMAP prevention can work only with programs that have at least
>   partial RELRO support. It's disabled automatically for programs that
>   lack this feature. It will cause problems to any program that uses dlopen
>   or tries to do an executable mmap. Unfortunately this feature is the one
>   that could create most problems and should be enabled only after careful
>   evaluation.
> To extend the scope of the above features, despite the issues that they may
> cause, they are complemented by:
> - procattr interface: can be used by a program to discover which WX
> Protection features are enabled and/or to tighten
> them.
> - Trampoline emulation: emulates the execution of well-known "trampolines"
>   even when they are placed in non-executable memory.
> Parts of WX Protection are inspired by some of the features available in
> PaX.
> 
> More information can be found in the documentation introduced in the first
> patch and in the "commit message" of the following emails.
> 
> [1] https://github.com/smeso/saractl
> [2] https://github.com/smeso/sara-test
> 
> Salvatore Mesoraca (11):
>   S.A.R.A. Documentation
>   S.A.R.A. framework creation
>   Creation of "usb_device_auth" LSM hook
>   S.A.R.A. USB Filtering
>   Creation of "check_vmflags" LSM hook
>   S.A.R.A. cred blob management
>   S.A.R.A. WX Protection
>   Creation of "pagefault_handler_x86" LSM hook
>   Trampoline emulation
>   Allowing for stacking procattr 

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Mickaël Salaün]

Hi,

I think it make sense to merge the W^X features with the TPE/shebang LSM
[1].

Regards,
 Mickaël

[1]
https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net

On 12/06/2017 18:56, Salvatore Mesoraca wrote:
> S.A.R.A. (S.A.R.A. is Another Recursive Acronym) is a stacked Linux
> Security Module that aims to collect heterogeneous security measures,
> providing a common interface to manage them.
> It can be useful to allow minor security features to use advanced
> management options, like user-space configuration files and tools, without
> too much overhead.
> Some submodules that use this framework are also introduced.
> The code is quite long, I apologize for this. Thank you in advance to
> anyone who will take the time to review this patchset.
> 
> S.A.R.A. is meant to be stacked but it needs cred blobs and the procattr
> interface, so I temporarily implemented those parts in a way that won't
> be acceptable for upstream, but it works for now. I know that there
> is some ongoing work to make cred blobs and procattr stackable, as soon
> as the new interfaces will be available I'll reimplement the involved
> parts.
> At the moment I've been able to test it only on x86.
> 
> S.A.R.A. submodules introduced in this patchset are: USB Filtering and
> WX Protection.
> 
> The kernel-space part is complemented by its user-space counterpart:
> saractl [1].
> A test suite for WX Protection, called sara-test [2], is also available.
> 
> USB Filtering aims to provide a mechanism to decide which USB devices
> should be authorized to connect to the system and which shouldn't. The main
> goal is to narrow the attack surface for custom USB devices designed to
> exploit vulnerabilities found in some USB device drivers.
> Via configuration it's possible to allow or to deny authorization, based
> on one or more of: Vendor ID, Product ID, bus name and port number. There
> is also limited support for wildcards.
> Depending on the configuration, it can work both as a white list or as a
> black list.
> With the help of "saractl" it's also possible to completely disable new
> USB devices when the screen is "locked".
> The original idea is inspired by the Grsecurity "Deny USB" feature.
> 
> WX Protection aims to improve user-space programs security by applying:
> - W^X enforcement: program can't have a page of memory that is marked, at
>  the same time, writable and executable.
> - W!->X restriction: any page that could have been marked as writable in
>the past won't ever be allowed to be marked as
>executable.
> - Executable MMAP prevention: prevents the creation of new executable mmaps
> after the dynamic libraries have been loaded.
> All of the above features can be enabled or disabled both system wide
> or on a per executable basis through the use of configuration files managed
> by "saractl".
> It is important to note that some programs may have issues working with
> WX Protection. In particular:
> - W^X enforcement will cause problems to any programs that needs
>   memory pages mapped both as writable and executable at the same time e.g.
>   programs with executable stack markings in the PT_GNU_STACK segment.
> - W!->X restriction will cause problems to any program that
>   needs to generate executable code at run time or to modify executable
>   pages e.g. programs with a JIT compiler built-in or linked against a
>   non-PIC library.
> - Executable MMAP prevention can work only with programs that have at least
>   partial RELRO support. It's disabled automatically for programs that
>   lack this feature. It will cause problems to any program that uses dlopen
>   or tries to do an executable mmap. Unfortunately this feature is the one
>   that could create most problems and should be enabled only after careful
>   evaluation.
> To extend the scope of the above features, despite the issues that they may
> cause, they are complemented by:
> - procattr interface: can be used by a program to discover which WX
> Protection features are enabled and/or to tighten
> them.
> - Trampoline emulation: emulates the execution of well-known "trampolines"
>   even when they are placed in non-executable memory.
> Parts of WX Protection are inspired by some of the features available in
> PaX.
> 
> More information can be found in the documentation introduced in the first
> patch and in the "commit message" of the following emails.
> 
> [1] https://github.com/smeso/saractl
> [2] https://github.com/smeso/sara-test
> 
> Salvatore Mesoraca (11):
>   S.A.R.A. Documentation
>   S.A.R.A. framework creation
>   Creation of "usb_device_auth" LSM hook
>   S.A.R.A. USB Filtering
>   Creation of "check_vmflags" LSM hook
>   S.A.R.A. cred blob management
>   S.A.R.A. WX Protection
>   Creation of "pagefault_handler_x86" LSM hook
>   Trampoline emulation
>   Allowing for stacking procattr