The secmark "one user" policy

The secmark "one user" policy

[Casey Schaufler]

I'm looking at the secmark code and am looking in
particular at the places where it explicitly says
that it is intended for one security module at a
time. For extreme stacking I can either enforce this
restriction by configuration or remove it by clever
uses of secid mappings. Either can be made "transparent"
to existing user-space. Paul has expressed distaste for
using configuration as a shortcut for dealing with this
kind of problem, and I generally agree with him. On the
other hand, the code is quite clear that it is designed
for one and only one kind of secid at a time. I don't
want to put a lot of effort into patches that are
unacceptable to the author.

Thank you.

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

The secmark "one user" policy

[James Morris]

On Tue, 20 Jun 2017, Casey Schaufler wrote:

> I'm looking at the secmark code and am looking in
> particular at the places where it explicitly says
> that it is intended for one security module at a
> time. For extreme stacking I can either enforce this
> restriction by configuration or remove it by clever
> uses of secid mappings. Either can be made "transparent"
> to existing user-space. Paul has expressed distaste for
> using configuration as a shortcut for dealing with this
> kind of problem, and I generally agree with him. On the
> other hand, the code is quite clear that it is designed
> for one and only one kind of secid at a time. I don't
> want to put a lot of effort into patches that are
> unacceptable to the author.

How would you see this working, ideally?


-- 
James Morris
<jmorris@namei.org>

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

The secmark "one user" policy

[Casey Schaufler]

On 6/21/2017 12:13 AM, James Morris wrote:
> On Tue, 20 Jun 2017, Casey Schaufler wrote:
>
>> I'm looking at the secmark code and am looking in
>> particular at the places where it explicitly says
>> that it is intended for one security module at a
>> time. For extreme stacking I can either enforce this
>> restriction by configuration or remove it by clever
>> uses of secid mappings. Either can be made "transparent"
>> to existing user-space. Paul has expressed distaste for
>> using configuration as a shortcut for dealing with this
>> kind of problem, and I generally agree with him. On the
>> other hand, the code is quite clear that it is designed
>> for one and only one kind of secid at a time. I don't
>> want to put a lot of effort into patches that are
>> unacceptable to the author.
> How would you see this working, ideally?

Ideally there would be a separate secmark for each security
module that wants to use the mechanism. Mechanism would be
provided* so that user-space can identify which security
module it is referring to when interacting with the kernel.
My understanding is that we're unlikely to get an expanded
secmark, so I have concentrated elsewhere.

A "clever" secid mapping takes the secids from all the
security modules and gently manipulates them until they
fit into a single u32. This might be an index into a list
of secid sets, but if you have two modules using secids
you can give each half of the secmark and accommodate
many configurations, including Fedora. Again, you need
mechanism* for user-space. This option would require changes
to the xt_SECMARK implementation, which goes out of it's
way to ensure all secmarks come from the same security
module. One option is to add a SECMARK_MODE_COMPOUND, but
that isn't any more helpful then removing the restriction.

As for configuration options, SELinux only uses secmarks
when user-space introduces them. If netfilter doesn't have
any security rules that add secmarks, none are used. Smack
can be configured to set secmarks on all packets, with the
potential for change by user-space, but can also be set up
without any use of secmarks. There doesn't need to be any
significant change to xt_SECMARK if it is important to
maintain the "one user" model. Requiring that the user-space
use of netfilter be sane for the multiple security module
case (e.g. don't use SELinux firewall if Smack has the
secmark) seems somewhat reasonable.

I can work with any of these three solutions. Multiple
secmarks would be ideal, but I understand is a lost cause.
Clever secids add overhead and complexity. Restricting
configuration options is unsavory, but I don't think
unreasonably so.

---
* There's already need to identity which security module
you're dealing with at a given time for SO_PEERSEC and
/proc/.../attr/current. In the past I've suggested decorating
attribute values with the name of the module (smack='System')
but I'm currently leaning more toward a prctl() to set the
value if you don't want to get whatever comes first. That
should maximize the effectiveness of existing user-space
tools.

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

The secmark "one user" policy

[John Johansen]

On 06/21/2017 08:23 AM, Casey Schaufler wrote:
> On 6/21/2017 12:13 AM, James Morris wrote:
>> On Tue, 20 Jun 2017, Casey Schaufler wrote:
>>
>>> I'm looking at the secmark code and am looking in
>>> particular at the places where it explicitly says
>>> that it is intended for one security module at a
>>> time. For extreme stacking I can either enforce this
>>> restriction by configuration or remove it by clever
>>> uses of secid mappings. Either can be made "transparent"
>>> to existing user-space. Paul has expressed distaste for
>>> using configuration as a shortcut for dealing with this
>>> kind of problem, and I generally agree with him. On the
>>> other hand, the code is quite clear that it is designed
>>> for one and only one kind of secid at a time. I don't
>>> want to put a lot of effort into patches that are
>>> unacceptable to the author.
>> How would you see this working, ideally?
> 
> Ideally there would be a separate secmark for each security
> module that wants to use the mechanism. Mechanism would be
> provided* so that user-space can identify which security
> module it is referring to when interacting with the kernel.
> My understanding is that we're unlikely to get an expanded
> secmark, so I have concentrated elsewhere.
> 
> A "clever" secid mapping takes the secids from all the
> security modules and gently manipulates them until they
> fit into a single u32. This might be an index into a list
> of secid sets, but if you have two modules using secids
> you can give each half of the secmark and accommodate
> many configurations, including Fedora. Again, you need
> mechanism* for user-space. This option would require changes
> to the xt_SECMARK implementation, which goes out of it's
> way to ensure all secmarks come from the same security
> module. One option is to add a SECMARK_MODE_COMPOUND, but
> that isn't any more helpful then removing the restriction.
> 
> As for configuration options, SELinux only uses secmarks
> when user-space introduces them. If netfilter doesn't have
> any security rules that add secmarks, none are used. Smack
> can be configured to set secmarks on all packets, with the
> potential for change by user-space, but can also be set up
> without any use of secmarks. There doesn't need to be any
> significant change to xt_SECMARK if it is important to
> maintain the "one user" model. Requiring that the user-space
> use of netfilter be sane for the multiple security module
> case (e.g. don't use SELinux firewall if Smack has the
> secmark) seems somewhat reasonable.
> 
> I can work with any of these three solutions. Multiple
> secmarks would be ideal, but I understand is a lost cause.
> Clever secids add overhead and complexity. Restricting
> configuration options is unsavory, but I don't think
> unreasonably so.
> 

I too would prefer multiple secmarks, but doing some sort of mapping
seems like what we will be stuck with. For a first pass I think the
restricted configurations options is reasonable, but I think it will
become a problem as people start trying to actually use LSM stacking.

I think for now sticking with restricted configurations and dealing
with mappings when it becomes an actual issue and we have better use
cases is not an unreasonable approach.

> ---
> * There's already need to identity which security module
> you're dealing with at a given time for SO_PEERSEC and
> /proc/.../attr/current. In the past I've suggested decorating
> attribute values with the name of the module (smack='System')
> but I'm currently leaning more toward a prctl() to set the
> value if you don't want to get whatever comes first. That
> should maximize the effectiveness of existing user-space
> tools.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

The secmark "one user" policy

[Casey Schaufler]

On 6/21/2017 4:07 PM, John Johansen wrote:
> On 06/21/2017 08:23 AM, Casey Schaufler wrote:
>> On 6/21/2017 12:13 AM, James Morris wrote:
>>> On Tue, 20 Jun 2017, Casey Schaufler wrote:
>>>
>>>> I'm looking at the secmark code and am looking in
>>>> particular at the places where it explicitly says
>>>> that it is intended for one security module at a
>>>> time. For extreme stacking I can either enforce this
>>>> restriction by configuration or remove it by clever
>>>> uses of secid mappings. Either can be made "transparent"
>>>> to existing user-space. Paul has expressed distaste for
>>>> using configuration as a shortcut for dealing with this
>>>> kind of problem, and I generally agree with him. On the
>>>> other hand, the code is quite clear that it is designed
>>>> for one and only one kind of secid at a time. I don't
>>>> want to put a lot of effort into patches that are
>>>> unacceptable to the author.
>>> How would you see this working, ideally?
>> Ideally there would be a separate secmark for each security
>> module that wants to use the mechanism. Mechanism would be
>> provided* so that user-space can identify which security
>> module it is referring to when interacting with the kernel.
>> My understanding is that we're unlikely to get an expanded
>> secmark, so I have concentrated elsewhere.
>>
>> A "clever" secid mapping takes the secids from all the
>> security modules and gently manipulates them until they
>> fit into a single u32. This might be an index into a list
>> of secid sets, but if you have two modules using secids
>> you can give each half of the secmark and accommodate
>> many configurations, including Fedora. Again, you need
>> mechanism* for user-space. This option would require changes
>> to the xt_SECMARK implementation, which goes out of it's
>> way to ensure all secmarks come from the same security
>> module. One option is to add a SECMARK_MODE_COMPOUND, but
>> that isn't any more helpful then removing the restriction.
>>
>> As for configuration options, SELinux only uses secmarks
>> when user-space introduces them. If netfilter doesn't have
>> any security rules that add secmarks, none are used. Smack
>> can be configured to set secmarks on all packets, with the
>> potential for change by user-space, but can also be set up
>> without any use of secmarks. There doesn't need to be any
>> significant change to xt_SECMARK if it is important to
>> maintain the "one user" model. Requiring that the user-space
>> use of netfilter be sane for the multiple security module
>> case (e.g. don't use SELinux firewall if Smack has the
>> secmark) seems somewhat reasonable.
>>
>> I can work with any of these three solutions. Multiple
>> secmarks would be ideal, but I understand is a lost cause.
>> Clever secids add overhead and complexity. Restricting
>> configuration options is unsavory, but I don't think
>> unreasonably so.
>>
> I too would prefer multiple secmarks, but doing some sort of mapping
> seems like what we will be stuck with. For a first pass I think the
> restricted configurations options is reasonable, but I think it will
> become a problem as people start trying to actually use LSM stacking.
>
> I think for now sticking with restricted configurations and dealing
> with mappings when it becomes an actual issue and we have better use
> cases is not an unreasonable approach.

It boils down to how many security modules are going to
implement network controls that require passing information
with the packet. I can easily see a bunch of use cases
beyond what SELinux and Smack do, but I can't say that I'd
see those used in conjunction with the "old school" security
modules. We can have a lousy mapping scheme if we don't
expect it to be used except in unnatural cases.

Is AppArmor going to be using secmarks? I haven't looked at
what's going into 4.13 yet. If you are, are they required or
optional, or used when netfilter assigns them?

>> ---
>> * There's already need to identity which security module
>> you're dealing with at a given time for SO_PEERSEC and
>> /proc/.../attr/current. In the past I've suggested decorating
>> attribute values with the name of the module (smack='System')
>> but I'm currently leaning more toward a prctl() to set the
>> value if you don't want to get whatever comes first. That
>> should maximize the effectiveness of existing user-space
>> tools.
>>

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

The secmark "one user" policy

[John Johansen]

On 06/21/2017 04:45 PM, Casey Schaufler wrote:
> On 6/21/2017 4:07 PM, John Johansen wrote:
>> On 06/21/2017 08:23 AM, Casey Schaufler wrote:
>>> On 6/21/2017 12:13 AM, James Morris wrote:
>>>> On Tue, 20 Jun 2017, Casey Schaufler wrote:
>>>>
>>>>> I'm looking at the secmark code and am looking in
>>>>> particular at the places where it explicitly says
>>>>> that it is intended for one security module at a
>>>>> time. For extreme stacking I can either enforce this
>>>>> restriction by configuration or remove it by clever
>>>>> uses of secid mappings. Either can be made "transparent"
>>>>> to existing user-space. Paul has expressed distaste for
>>>>> using configuration as a shortcut for dealing with this
>>>>> kind of problem, and I generally agree with him. On the
>>>>> other hand, the code is quite clear that it is designed
>>>>> for one and only one kind of secid at a time. I don't
>>>>> want to put a lot of effort into patches that are
>>>>> unacceptable to the author.
>>>> How would you see this working, ideally?
>>> Ideally there would be a separate secmark for each security
>>> module that wants to use the mechanism. Mechanism would be
>>> provided* so that user-space can identify which security
>>> module it is referring to when interacting with the kernel.
>>> My understanding is that we're unlikely to get an expanded
>>> secmark, so I have concentrated elsewhere.
>>>
>>> A "clever" secid mapping takes the secids from all the
>>> security modules and gently manipulates them until they
>>> fit into a single u32. This might be an index into a list
>>> of secid sets, but if you have two modules using secids
>>> you can give each half of the secmark and accommodate
>>> many configurations, including Fedora. Again, you need
>>> mechanism* for user-space. This option would require changes
>>> to the xt_SECMARK implementation, which goes out of it's
>>> way to ensure all secmarks come from the same security
>>> module. One option is to add a SECMARK_MODE_COMPOUND, but
>>> that isn't any more helpful then removing the restriction.
>>>
>>> As for configuration options, SELinux only uses secmarks
>>> when user-space introduces them. If netfilter doesn't have
>>> any security rules that add secmarks, none are used. Smack
>>> can be configured to set secmarks on all packets, with the
>>> potential for change by user-space, but can also be set up
>>> without any use of secmarks. There doesn't need to be any
>>> significant change to xt_SECMARK if it is important to
>>> maintain the "one user" model. Requiring that the user-space
>>> use of netfilter be sane for the multiple security module
>>> case (e.g. don't use SELinux firewall if Smack has the
>>> secmark) seems somewhat reasonable.
>>>
>>> I can work with any of these three solutions. Multiple
>>> secmarks would be ideal, but I understand is a lost cause.
>>> Clever secids add overhead and complexity. Restricting
>>> configuration options is unsavory, but I don't think
>>> unreasonably so.
>>>
>> I too would prefer multiple secmarks, but doing some sort of mapping
>> seems like what we will be stuck with. For a first pass I think the
>> restricted configurations options is reasonable, but I think it will
>> become a problem as people start trying to actually use LSM stacking.
>>
>> I think for now sticking with restricted configurations and dealing
>> with mappings when it becomes an actual issue and we have better use
>> cases is not an unreasonable approach.
> 
> It boils down to how many security modules are going to
> implement network controls that require passing information
> with the packet. I can easily see a bunch of use cases
> beyond what SELinux and Smack do, but I can't say that I'd
> see those used in conjunction with the "old school" security
> modules. We can have a lousy mapping scheme if we don't
> expect it to be used except in unnatural cases.
> 
> Is AppArmor going to be using secmarks? I haven't looked at
> what's going into 4.13 yet. If you are, are they required or
> optional, or used when netfilter assigns them?
>

4.13 doesn't have any of the networking stuff, it is just an
update of the mediation that is already there in 4.12, and the
rework of the apparmorfs code to use the securityfs symlink
support.

As for secmarks, yes we will be using them, I am still messing
with it, so there is room for change. AppArmor can certainly
offer a level of network support if they are optional, so
its likely we will do that.

They will certainly supported when netfilter assigns them, but
like we would like to also be able to assign them on packets,
again this could be a configuration option.

Hopefully I can get an RFC up soon, but I need to kick out the
namespacing RFC first.

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

The secmark "one user" policy

[James Morris]

On Wed, 21 Jun 2017, Casey Schaufler wrote:

> Ideally there would be a separate secmark for each security
> module that wants to use the mechanism. Mechanism would be
> provided* so that user-space can identify which security
> module it is referring to when interacting with the kernel.
> My understanding is that we're unlikely to get an expanded
> secmark, so I have concentrated elsewhere.

I don't see us getting an expanded secmark, either.

> 
> A "clever" secid mapping takes the secids from all the
> security modules and gently manipulates them until they
> fit into a single u32. This might be an index into a list
> of secid sets, but if you have two modules using secids
> you can give each half of the secmark and accommodate
> many configurations, including Fedora. Again, you need
> mechanism* for user-space. This option would require changes
> to the xt_SECMARK implementation, which goes out of it's
> way to ensure all secmarks come from the same security
> module. One option is to add a SECMARK_MODE_COMPOUND, but
> that isn't any more helpful then removing the restriction.

This sounds very ugly, and each user may assume it has 32 bits of secmark.

> As for configuration options, SELinux only uses secmarks
> when user-space introduces them. If netfilter doesn't have
> any security rules that add secmarks, none are used. Smack
> can be configured to set secmarks on all packets, with the
> potential for change by user-space, but can also be set up
> without any use of secmarks. There doesn't need to be any
> significant change to xt_SECMARK if it is important to
> maintain the "one user" model. Requiring that the user-space
> use of netfilter be sane for the multiple security module
> case (e.g. don't use SELinux firewall if Smack has the
> secmark) seems somewhat reasonable.

Reasonable?  I don't think so.  

Trying to stack major LSMs arbitrarily and exposing that to userland is an 
architectural mess, which is what these kinds of problems are really 
telling us.

How can a user be expected to reason about a system which is running 
multiple independent MAC security models simultaneously?  It's a terrible 
idea.


-- 
James Morris
<jmorris@namei.org>

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

The secmark "one user" policy

[Casey Schaufler]

On 6/22/2017 2:54 AM, James Morris wrote:
> On Wed, 21 Jun 2017, Casey Schaufler wrote:
>
>> Ideally there would be a separate secmark for each security
>> module that wants to use the mechanism. Mechanism would be
>> provided* so that user-space can identify which security
>> module it is referring to when interacting with the kernel.
>> My understanding is that we're unlikely to get an expanded
>> secmark, so I have concentrated elsewhere.
> I don't see us getting an expanded secmark, either.
>
>> A "clever" secid mapping takes the secids from all the
>> security modules and gently manipulates them until they
>> fit into a single u32. This might be an index into a list
>> of secid sets, but if you have two modules using secids
>> you can give each half of the secmark and accommodate
>> many configurations, including Fedora. Again, you need
>> mechanism* for user-space. This option would require changes
>> to the xt_SECMARK implementation, which goes out of it's
>> way to ensure all secmarks come from the same security
>> module. One option is to add a SECMARK_MODE_COMPOUND, but
>> that isn't any more helpful then removing the restriction.
> This sounds very ugly, and each user may assume it has 32 bits of secmark.

The "two in one" doesn't scale, as well as being ugly and limited.
An index scheme, where there's a table mapping N to 1 is at least
as ugly and will do horrible things to performance.

>> As for configuration options, SELinux only uses secmarks
>> when user-space introduces them. If netfilter doesn't have
>> any security rules that add secmarks, none are used. Smack
>> can be configured to set secmarks on all packets, with the
>> potential for change by user-space, but can also be set up
>> without any use of secmarks. There doesn't need to be any
>> significant change to xt_SECMARK if it is important to
>> maintain the "one user" model. Requiring that the user-space
>> use of netfilter be sane for the multiple security module
>> case (e.g. don't use SELinux firewall if Smack has the
>> secmark) seems somewhat reasonable.
> Reasonable?  I don't think so.  
>
> Trying to stack major LSMs arbitrarily and exposing that to userland is an 
> architectural mess,

I agree that it would be an administrative nightmare to produce
a viable combination of SELinux, Smack, AppArmor and/or TOMOYO.
I also agree that anyone who thinks it's a good idea to do so
should investigate further what they're trying to accomplish.

>  which is what these kinds of problems are really telling us.

James, I respect you greatly, but disagree with you completely.
The problems with secids and secmarks have nothing to do with
the complexity of administering policy. They are issues of an
architecture that doesn't scale beyond unity.

> How can a user be expected to reason about a system which is running 
> multiple independent MAC security models simultaneously?

The combination of SELinux, Smack, AppArmor and/or TOMOYO is not
the goal so much as the test case. MAC was the coolest possible
technology in 1990. We've implemented it. I don't see anyone doing
a new MAC implementation. I *do* see security modules that implement
other security models in the pipeline. Some of these need to maintain
state, which means using security blobs in the LSM architecture.
Some of these models will want to use secmarks to implement socket
based controls. If we can provide for SELinux+Smack* we can be
confident that we can support anything today's kids want to throw
at us. If we blow that off Linux won't be able to adapt to the
security needs of the future.

> It's a terrible idea.

As I keep saying, SELinux+Smack is not the point of
complete module stacking. SELinux combined with a time
based module, or Smack with Landlock and Tags is the
point. It's the future. The technical issues are the same.
That is why I persist in the effort to make the existing
modules stack together.

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

The secmark "one user" policy

[John Johansen]

On 06/22/2017 02:54 AM, James Morris wrote:
> On Wed, 21 Jun 2017, Casey Schaufler wrote:
> 
>> Ideally there would be a separate secmark for each security
>> module that wants to use the mechanism. Mechanism would be
>> provided* so that user-space can identify which security
>> module it is referring to when interacting with the kernel.
>> My understanding is that we're unlikely to get an expanded
>> secmark, so I have concentrated elsewhere.
> 
> I don't see us getting an expanded secmark, either.
> 
>>
>> A "clever" secid mapping takes the secids from all the
>> security modules and gently manipulates them until they
>> fit into a single u32. This might be an index into a list
>> of secid sets, but if you have two modules using secids
>> you can give each half of the secmark and accommodate
>> many configurations, including Fedora. Again, you need
>> mechanism* for user-space. This option would require changes
>> to the xt_SECMARK implementation, which goes out of it's
>> way to ensure all secmarks come from the same security
>> module. One option is to add a SECMARK_MODE_COMPOUND, but
>> that isn't any more helpful then removing the restriction.
> 
> This sounds very ugly, and each user may assume it has 32 bits of secmark.
> 
>> As for configuration options, SELinux only uses secmarks
>> when user-space introduces them. If netfilter doesn't have
>> any security rules that add secmarks, none are used. Smack
>> can be configured to set secmarks on all packets, with the
>> potential for change by user-space, but can also be set up
>> without any use of secmarks. There doesn't need to be any
>> significant change to xt_SECMARK if it is important to
>> maintain the "one user" model. Requiring that the user-space
>> use of netfilter be sane for the multiple security module
>> case (e.g. don't use SELinux firewall if Smack has the
>> secmark) seems somewhat reasonable.
> 
> Reasonable?  I don't think so.  
> 
> Trying to stack major LSMs arbitrarily and exposing that to userland is an 
> architectural mess, which is what these kinds of problems are really 
> telling us.
> 

The use case I keep seeing is not exposing multiple LSMs to the user
space. Its the container where the container wants a different LSM
than the system is running.

Stacking 2 LSMs in that case and only exposing one to user space isn't
so unreasonable.

> How can a user be expected to reason about a system which is running 
> multiple independent MAC security models simultaneously?  It's a terrible 
> idea.
> 

At a generic system MAC level I agree, but not all LSMs that need
state are MACs and in the more limited container case it isn't so
unreasonable.  Arguably virtualization is a better solution for the
container that wants a different MAC but then that forces you to
choose virtualization from the start and not just use the existing pre
built container that you want to pull in and use.

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

The secmark "one user" policy

[Paul Moore]

On Wed, Jun 21, 2017 at 11:23 AM, Casey Schaufler
<casey@schaufler-ca.com> wrote:
> On 6/21/2017 12:13 AM, James Morris wrote:
>> On Tue, 20 Jun 2017, Casey Schaufler wrote:
>>
>>> I'm looking at the secmark code and am looking in
>>> particular at the places where it explicitly says
>>> that it is intended for one security module at a
>>> time. For extreme stacking I can either enforce this
>>> restriction by configuration or remove it by clever
>>> uses of secid mappings. Either can be made "transparent"
>>> to existing user-space. Paul has expressed distaste for
>>> using configuration as a shortcut for dealing with this
>>> kind of problem, and I generally agree with him. On the
>>> other hand, the code is quite clear that it is designed
>>> for one and only one kind of secid at a time. I don't
>>> want to put a lot of effort into patches that are
>>> unacceptable to the author.

We've talked about these problems quite a bit the past few years,
although I believe most of those discussions have occurred in hallways
and bars, and with a random collection of bored, uninterested, or
frightened contributors.  Let me try to summarize my thoughts a bit
below ...

>> How would you see this working, ideally?
>
> Ideally there would be a separate secmark for each security
> module that wants to use the mechanism. Mechanism would be
> provided* so that user-space can identify which security
> module it is referring to when interacting with the kernel.
> My understanding is that we're unlikely to get an expanded
> secmark, so I have concentrated elsewhere.

I think "unlikely" is putting it kindly when it comes to an expanded secmark.

However, expanding the secmark isn't really the solution we need, or
want for that matter.  The core of the problem is that we don't have a
security pointer/blob in the skb, and unfortunately, just like an
expanded secmark, it isn't going to happen ... at least not in the
traditional sense.

> A "clever" secid mapping takes the secids from all the
> security modules and gently manipulates them until they
> fit into a single u32. This might be an index into a list
> of secid sets ...

As we've talked about before, I believe the only real general solution
to this problem is to use the secmark as an index into some
list/array/???/datastore that acts like a traditional LSM security
blob.  The blob could contain whatever the LSM requires: a secmark, a
peer label, and/or whatever else comes up later down the line.  While
painful, I'm hopeful that we could do this in a way which wouldn't
completely tank performance, and I expect that reference counting
could be used to help limit memory pressure in most of the current use
cases.  This would likely require a few more hooks (I think, it has
been about a year since I looked into this last), but based on my last
go-round with DaveM the additional hooks weren't a major source of
concern for him.

This approach would also have the advantage of finally allowing us to
handle traffic forwarding in a proper manner.  It's a big mess at the
moment and depending on how your network labeling is configured it
may, or may not, work.  As software based switches grow in importance
for cloud based solutions, having proper LSM per-packet forwarding
controls becomes more important (IMHO).

> ... but if you have two modules using secids
> you can give each half of the secmark and accommodate
> many configurations, including Fedora. Again, you need
> mechanism* for user-space. This option would require changes
> to the xt_SECMARK implementation, which goes out of it's
> way to ensure all secmarks come from the same security
> module. One option is to add a SECMARK_MODE_COMPOUND, but
> that isn't any more helpful then removing the restriction.

I don't mean to make light of this as an issue, but I think we have
larger problems to deal with first (see above).  I think once we solve
those we should be able to deal with this in a reasonable manner.

> As for configuration options, SELinux only uses secmarks
> when user-space introduces them. If netfilter doesn't have
> any security rules that add secmarks, none are used. Smack
> can be configured to set secmarks on all packets, with the
> potential for change by user-space, but can also be set up
> without any use of secmarks. There doesn't need to be any
> significant change to xt_SECMARK if it is important to
> maintain the "one user" model. Requiring that the user-space
> use of netfilter be sane for the multiple security module
> case (e.g. don't use SELinux firewall if Smack has the
> secmark) seems somewhat reasonable.

Ugh, no.  Please, no.  The configuration route is tempting because it
is easy, but just think of the users, the poor confused admins.
Seriously, think of them, because they are just going to configure the
LSMs the way they do now and some of them are going to have a
configuration the either 1) doesn't work and they will (rightly)
complain or 2) blows up in their face with a kernel panic, a
relabeling bug, or something else equally nasty.

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

The secmark "one user" policy

[Casey Schaufler]

On 6/22/2017 3:24 PM, Paul Moore wrote:
> On Wed, Jun 21, 2017 at 11:23 AM, Casey Schaufler
> <casey@schaufler-ca.com> wrote:
>> On 6/21/2017 12:13 AM, James Morris wrote:
>>> On Tue, 20 Jun 2017, Casey Schaufler wrote:
>>>
>>>> I'm looking at the secmark code and am looking in
>>>> particular at the places where it explicitly says
>>>> that it is intended for one security module at a
>>>> time. For extreme stacking I can either enforce this
>>>> restriction by configuration or remove it by clever
>>>> uses of secid mappings. Either can be made "transparent"
>>>> to existing user-space. Paul has expressed distaste for
>>>> using configuration as a shortcut for dealing with this
>>>> kind of problem, and I generally agree with him. On the
>>>> other hand, the code is quite clear that it is designed
>>>> for one and only one kind of secid at a time. I don't
>>>> want to put a lot of effort into patches that are
>>>> unacceptable to the author.
> We've talked about these problems quite a bit the past few years,
> although I believe most of those discussions have occurred in hallways
> and bars, and with a random collection of bored, uninterested, or
> frightened contributors.  Let me try to summarize my thoughts a bit
> below ...

... Which is the right way to discuss these things, although
I have been warned about frightening the contributors.

>>> How would you see this working, ideally?
>> Ideally there would be a separate secmark for each security
>> module that wants to use the mechanism. Mechanism would be
>> provided* so that user-space can identify which security
>> module it is referring to when interacting with the kernel.
>> My understanding is that we're unlikely to get an expanded
>> secmark, so I have concentrated elsewhere.
> I think "unlikely" is putting it kindly when it comes to an expanded secmark.
>
> However, expanding the secmark isn't really the solution we need, or
> want for that matter.  The core of the problem is that we don't have a
> security pointer/blob in the skb, and unfortunately, just like an
> expanded secmark, it isn't going to happen ... at least not in the
> traditional sense.

I had been thinking in terms of a blob that contains the
various secids provided by the modules, but a blob that contains
more/other information has possibilities. Hmm.

>> A "clever" secid mapping takes the secids from all the
>> security modules and gently manipulates them until they
>> fit into a single u32. This might be an index into a list
>> of secid sets ...
> As we've talked about before, I believe the only real general solution
> to this problem is to use the secmark as an index into some
> list/array/???/datastore that acts like a traditional LSM security
> blob.  The blob could contain whatever the LSM requires: a secmark, a
> peer label, and/or whatever else comes up later down the line.  While
> painful, I'm hopeful that we could do this in a way which wouldn't
> completely tank performance, and I expect that reference counting
> could be used to help limit memory pressure in most of the current use
> cases.  This would likely require a few more hooks (I think, it has
> been about a year since I looked into this last), but based on my last
> go-round with DaveM the additional hooks weren't a major source of
> concern for him.

The specific concern I have here is that the code in xt_SECMARK wants
you to declare a specific security module when using secmarks.

> This approach would also have the advantage of finally allowing us to
> handle traffic forwarding in a proper manner.  It's a big mess at the
> moment and depending on how your network labeling is configured it
> may, or may not, work.  As software based switches grow in importance
> for cloud based solutions, having proper LSM per-packet forwarding
> controls becomes more important (IMHO).

I confess to having spent no time on the traffic forwarding
implementation. I didn't know there was an issue, but now that
I do it will influence my choices.


>> ... but if you have two modules using secids
>> you can give each half of the secmark and accommodate
>> many configurations, including Fedora. Again, you need
>> mechanism* for user-space. This option would require changes
>> to the xt_SECMARK implementation, which goes out of it's
>> way to ensure all secmarks come from the same security
>> module. One option is to add a SECMARK_MODE_COMPOUND, but
>> that isn't any more helpful then removing the restriction.
> I don't mean to make light of this as an issue, but I think we have
> larger problems to deal with first (see above).  I think once we solve
> those we should be able to deal with this in a reasonable manner.

Lining up for the eventuality.


>> As for configuration options, SELinux only uses secmarks
>> when user-space introduces them. If netfilter doesn't have
>> any security rules that add secmarks, none are used. Smack
>> can be configured to set secmarks on all packets, with the
>> potential for change by user-space, but can also be set up
>> without any use of secmarks. There doesn't need to be any
>> significant change to xt_SECMARK if it is important to
>> maintain the "one user" model. Requiring that the user-space
>> use of netfilter be sane for the multiple security module
>> case (e.g. don't use SELinux firewall if Smack has the
>> secmark) seems somewhat reasonable.
> Ugh, no.  Please, no.  The configuration route is tempting because it
> is easy, but just think of the users, the poor confused admins.
> Seriously, think of them, because they are just going to configure the
> LSMs the way they do now and some of them are going to have a
> configuration the either 1) doesn't work and they will (rightly)
> complain or 2) blows up in their face with a kernel panic, a
> relabeling bug, or something else equally nasty.

Regardless of what we do there will be configurations
that just won't be possible to make work. A Tizen Smack
configuration and a DoD SELinux MLS internal network
setup would be pretty well guaranteed to result in no
packets being delivered in either direction. You've worked
on putting distributions together, so you know that at
some point there have to be limits on just how general
any "solution" can be.

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

The secmark "one user" policy

[James Morris]

On Thu, 22 Jun 2017, John Johansen wrote:

> > Trying to stack major LSMs arbitrarily and exposing that to userland is an 
> > architectural mess, which is what these kinds of problems are really 
> > telling us.
> > 
> 
> The use case I keep seeing is not exposing multiple LSMs to the user
> space. Its the container where the container wants a different LSM
> than the system is running.
> 
> Stacking 2 LSMs in that case and only exposing one to user space isn't
> so unreasonable.

In this case, would they both be labeling LSMs which need to label 
packets?

I can imagine having Smack or SELinux as the base LSM and then having 
AppArmor in the container, but having Smack and SELinux in that 
combination would still not make sense to me.

> 
> > How can a user be expected to reason about a system which is running 
> > multiple independent MAC security models simultaneously?  It's a terrible 
> > idea.
> > 
> 
> At a generic system MAC level I agree, but not all LSMs that need
> state are MACs and in the more limited container case it isn't so
> unreasonable.

Can you provide a concrete example of needing two independent packet 
labeling LSMs?


-- 
James Morris
<jmorris@namei.org>

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

The secmark "one user" policy

[James Morris]

On Thu, 22 Jun 2017, Casey Schaufler wrote:

> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not
> the goal so much as the test case. MAC was the coolest possible
> technology in 1990. We've implemented it. I don't see anyone doing
> a new MAC implementation. I *do* see security modules that implement
> other security models in the pipeline. Some of these need to maintain
> state, which means using security blobs in the LSM architecture.
> Some of these models will want to use secmarks to implement socket
> based controls.

Where are these LSMs and where are the discussions about their LSM API 
needs? 

-- 
James Morris
<jmorris@namei.org>

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

The secmark "one user" policy

[John Johansen]

On 06/22/2017 08:02 PM, James Morris wrote:
> On Thu, 22 Jun 2017, John Johansen wrote:
> 
>>> Trying to stack major LSMs arbitrarily and exposing that to userland is an 
>>> architectural mess, which is what these kinds of problems are really 
>>> telling us.
>>>
>>
>> The use case I keep seeing is not exposing multiple LSMs to the user
>> space. Its the container where the container wants a different LSM
>> than the system is running.
>>
>> Stacking 2 LSMs in that case and only exposing one to user space isn't
>> so unreasonable.
> 
> In this case, would they both be labeling LSMs which need to label 
> packets?
> 
> I can imagine having Smack or SELinux as the base LSM and then having 
> AppArmor in the container, but having Smack and SELinux in that 
> combination would still not make sense to me.
> 

I don't see why not. The container could be built expecting smack
labeling, selinux applies 1 or just a few labels to the whole
container, and accesses within the container are mediated fine grained
with smack.

If you are talking system containers like LXC/D this makes even more
sense, your running selinux on the host and the container is using smack
or AppArmor.

It does mean you would have to do some namespacing of some sort so that
the interface would know which LSM to multiplex to. Tasks in the container
write to smack or apparmor, system tasks get selinux.

selinux still gets to enforce a system policy even on the container as
it does today, and the other LSM applies policy as if the container is
the system (at least for system containers).

>>
>>> How can a user be expected to reason about a system which is running 
>>> multiple independent MAC security models simultaneously?  It's a terrible 
>>> idea.
>>>
>>
>> At a generic system MAC level I agree, but not all LSMs that need
>> state are MACs and in the more limited container case it isn't so
>> unreasonable.
> 
> Can you provide a concrete example of needing two independent packet 
> labeling LSMs?
> 

System containers come to mind, as mentioned above. Take an Ubuntu LXC
container and run it on fedora or RHEL. While apparmor isn't doing
packet label yet, patches for that should float up to the list soon,
and really it doesn't have to be ubuntu/apparmor the container guys
want to be a replacement for virtualization, allowing you to run
applications from different OSes on the same host.

You could take the same basic situation of an LXC container built
expecting smack and run it on fedora/RHEL with selinux enforcing for
the host. Except it isn't currently supported.

Right now LXC is limited as to what it can do with the MAC system in
the container. It can currently stack an apparmor host with an
apparmor guest each applying their own policy, but I know they would
love to be mix and match MAC systems, getting them closer to being a
replacement for virtualization. Again it could be argued that going
full virtualization is a better solution if you want different MAC
systems but people will choose (currently are choosing) to run the
container without a MAC instead of going with virtualization.

Another use case would be running snappy packages (chosen because it
is using apparmor to enforce some things, but same could be done with
flatpak if/when it starts using an LSM) on fedora. Currently you have
to either boot the system into apparmor (disabling selinux) or disable
part of the applications mediation. Again yes apparmor doesn't label
packets today but it will soon.

A little more speculatively another potential example would be an LSM
doing a personal firewalls around individual applications. Its really
very similar to the snappy/flatpak sandboxing of apps but maybe
someone wants that with out the additional baggage of a bigger LSM.
Whether it would ever get in upstream is a separate question.

I think we are just starting to scratch the surface of how stacking
will be used. Especially with all the different container/sandboxing
that is going on, and projects like flatpak and snappy pushing to be
system agnostic.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

The secmark "one user" policy

[Casey Schaufler]

On 6/22/2017 8:12 PM, James Morris wrote:
> On Thu, 22 Jun 2017, Casey Schaufler wrote:
>
>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not
>> the goal so much as the test case. MAC was the coolest possible
>> technology in 1990. We've implemented it. I don't see anyone doing
>> a new MAC implementation. I *do* see security modules that implement
>> other security models in the pipeline. Some of these need to maintain
>> state, which means using security blobs in the LSM architecture.
>> Some of these models will want to use secmarks to implement socket
>> based controls.
> Where are these LSMs and where are the discussions about their LSM API 
> needs? 

LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
have all been discussed on the LSM list in the past two years.
There is a growing interest in LSM as a hardening mechanism,
and there is discussion on kernel-hardening at lists.openwall.com.
I get inquiries from people who are considering writing, or
have started on new security modules but don't think they're
ready for general comment. This isn't surprising as I am the
vocal advocate for new, modern security modules. As you might
guess, some of those proposals never see wider discussion.

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

The secmark "one user" policy

[Paul Moore]

On Thu, Jun 22, 2017 at 7:20 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 6/22/2017 3:24 PM, Paul Moore wrote:
>> On Wed, Jun 21, 2017 at 11:23 AM, Casey Schaufler
>> <casey@schaufler-ca.com> wrote:
>>> On 6/21/2017 12:13 AM, James Morris wrote:
>>>> On Tue, 20 Jun 2017, Casey Schaufler wrote:

...

>>>> How would you see this working, ideally?
>>> Ideally there would be a separate secmark for each security
>>> module that wants to use the mechanism. Mechanism would be
>>> provided* so that user-space can identify which security
>>> module it is referring to when interacting with the kernel.
>>> My understanding is that we're unlikely to get an expanded
>>> secmark, so I have concentrated elsewhere.
>>
>> I think "unlikely" is putting it kindly when it comes to an expanded secmark.
>>
>> However, expanding the secmark isn't really the solution we need, or
>> want for that matter.  The core of the problem is that we don't have a
>> security pointer/blob in the skb, and unfortunately, just like an
>> expanded secmark, it isn't going to happen ... at least not in the
>> traditional sense.
>
> I had been thinking in terms of a blob that contains the
> various secids provided by the modules, but a blob that contains
> more/other information has possibilities. Hmm.

You *might* be able to get away with a blob that contains just secids
and is entirely managed at the LSM shim layer, but that is a big
missed opportunity as it doesn't really fix any of the problems we
have now that are caused by a lack of a skb security blob.  The jump
from a blob of secids to a set of LSM specific blobs is a very small
one and solves a lot of problems.  The hard bit is the
secmark-as-a-blob-index, once you've got that working, it shouldn't
matter quite as much what you are indexing.

>>> A "clever" secid mapping takes the secids from all the
>>> security modules and gently manipulates them until they
>>> fit into a single u32. This might be an index into a list
>>> of secid sets ...
>>
>> As we've talked about before, I believe the only real general solution
>> to this problem is to use the secmark as an index into some
>> list/array/???/datastore that acts like a traditional LSM security
>> blob.  The blob could contain whatever the LSM requires: a secmark, a
>> peer label, and/or whatever else comes up later down the line.  While
>> painful, I'm hopeful that we could do this in a way which wouldn't
>> completely tank performance, and I expect that reference counting
>> could be used to help limit memory pressure in most of the current use
>> cases.  This would likely require a few more hooks (I think, it has
>> been about a year since I looked into this last), but based on my last
>> go-round with DaveM the additional hooks weren't a major source of
>> concern for him.
>
> The specific concern I have here is that the code in xt_SECMARK wants
> you to declare a specific security module when using secmarks.

I understand, and perhaps I'm not thinking about it correctly, but I
just don't think it is as large a problem as you believe.  If it truly
is impossible to overcome, we can always create a SECMARK_STACKED
target or something.  I'm reasonably confident this is not the hard
part of this work.

>> This approach would also have the advantage of finally allowing us to
>> handle traffic forwarding in a proper manner.  It's a big mess at the
>> moment and depending on how your network labeling is configured it
>> may, or may not, work.  As software based switches grow in importance
>> for cloud based solutions, having proper LSM per-packet forwarding
>> controls becomes more important (IMHO).
>
> I confess to having spent no time on the traffic forwarding
> implementation. I didn't know there was an issue, but now that
> I do it will influence my choices.

Fun exercise: trace a packet through the forwarding path and watch as
it is either encapsulated or descapsulated by IPsec, similar problems
exist for IP tunnels/conversions (e.g. IPv6 <-> IPv4).

In order to solve this we need a security blob tied to the skb, we
can't rely on IP headers (CIPSO, CALIPSO) or xfrm state (labeled
IPsec).

>>> As for configuration options, SELinux only uses secmarks
>>> when user-space introduces them. If netfilter doesn't have
>>> any security rules that add secmarks, none are used. Smack
>>> can be configured to set secmarks on all packets, with the
>>> potential for change by user-space, but can also be set up
>>> without any use of secmarks. There doesn't need to be any
>>> significant change to xt_SECMARK if it is important to
>>> maintain the "one user" model. Requiring that the user-space
>>> use of netfilter be sane for the multiple security module
>>> case (e.g. don't use SELinux firewall if Smack has the
>>> secmark) seems somewhat reasonable.
>>
>> Ugh, no.  Please, no.  The configuration route is tempting because it
>> is easy, but just think of the users, the poor confused admins.
>> Seriously, think of them, because they are just going to configure the
>> LSMs the way they do now and some of them are going to have a
>> configuration the either 1) doesn't work and they will (rightly)
>> complain or 2) blows up in their face with a kernel panic, a
>> relabeling bug, or something else equally nasty.
>
> Regardless of what we do there will be configurations
> that just won't be possible to make work. A Tizen Smack
> configuration and a DoD SELinux MLS internal network
> setup would be pretty well guaranteed to result in no
> packets being delivered in either direction. You've worked
> on putting distributions together, so you know that at
> some point there have to be limits on just how general
> any "solution" can be.

The difference is that in this Smack-SELinux/MLS case it fails due to
security policy incompatibilities, not due to limitations in the LSM
or the LSM stacking layer.  I want to make sure that the LSM stacking
layer isn't the source of the problem.

NOTE: I'm intentionally avoiding the arguments regarding stacking
specific LSMs, e.g. Smack with SELinux, because I fear this brings us
back around to the old religious arguments.  I would encourage others
to do the same.  These debates were not constructive in the past, and
I don't believe they will be constructive now.

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

The secmark "one user" policy

[James Morris]

On Fri, 23 Jun 2017, Casey Schaufler wrote:

> On 6/22/2017 8:12 PM, James Morris wrote:
> > On Thu, 22 Jun 2017, Casey Schaufler wrote:
> >
> >> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not
> >> the goal so much as the test case. MAC was the coolest possible
> >> technology in 1990. We've implemented it. I don't see anyone doing
> >> a new MAC implementation. I *do* see security modules that implement
> >> other security models in the pipeline. Some of these need to maintain
> >> state, which means using security blobs in the LSM architecture.
> >> Some of these models will want to use secmarks to implement socket
> >> based controls.
> > Where are these LSMs and where are the discussions about their LSM API 
> > needs? 
> 
> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
> have all been discussed on the LSM list in the past two years.

Which of these need to use secmarks to implement socket controls?


-- 
James Morris
<jmorris@namei.org>

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

The secmark "one user" policy

[Casey Schaufler]

On 6/25/2017 2:41 AM, James Morris wrote:
> On Fri, 23 Jun 2017, Casey Schaufler wrote:
>
>> On 6/22/2017 8:12 PM, James Morris wrote:
>>> On Thu, 22 Jun 2017, Casey Schaufler wrote:
>>>
>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not
>>>> the goal so much as the test case. MAC was the coolest possible
>>>> technology in 1990. We've implemented it. I don't see anyone doing
>>>> a new MAC implementation. I *do* see security modules that implement
>>>> other security models in the pipeline. Some of these need to maintain
>>>> state, which means using security blobs in the LSM architecture.
>>>> Some of these models will want to use secmarks to implement socket
>>>> based controls.
>>> Where are these LSMs and where are the discussions about their LSM API 
>>> needs? 
>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
>> have all been discussed on the LSM list in the past two years.
> Which of these need to use secmarks to implement socket controls?

PTAGS doesn't, but will need to do so to be complete.

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

The secmark "one user" policy

[José Bollo]

On Sun, 25 Jun 2017 11:05:24 -0700
Casey Schaufler <casey@schaufler-ca.com> wrote:

> On 6/25/2017 2:41 AM, James Morris wrote:
> > On Fri, 23 Jun 2017, Casey Schaufler wrote:
> >  
> >> On 6/22/2017 8:12 PM, James Morris wrote:  
> >>> On Thu, 22 Jun 2017, Casey Schaufler wrote:
> >>>  
> >>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not
> >>>> the goal so much as the test case. MAC was the coolest possible
> >>>> technology in 1990. We've implemented it. I don't see anyone
> >>>> doing a new MAC implementation. I *do* see security modules that
> >>>> implement other security models in the pipeline. Some of these
> >>>> need to maintain state, which means using security blobs in the
> >>>> LSM architecture. Some of these models will want to use secmarks
> >>>> to implement socket based controls.  
> >>> Where are these LSMs and where are the discussions about their
> >>> LSM API needs?   
> >> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
> >> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
> >> have all been discussed on the LSM list in the past two years.  
> > Which of these need to use secmarks to implement socket controls?  
> 
> PTAGS doesn't, but will need to do so to be complete.

Hello Casey,

The very sleepy PTAGS is suddently awaken (at least one ear :^).

In my mind, PTAGS is dealing with processes. When packets are filtered,
the only revelent info is the emitter process. At the moment, I don't
see valuable situation where mediation isn't explicit thus faking origin
isn't needed.

So I would really like to understand your vision here. What do I miss?

Best regards
Jos?

PS. I reworked the TUI (Task Unic Id) and have something valuable now.
I haven't submitted it because I wanted to include a kind of FS library
to provide /proc like features. But it is a nightmare to find a minute
to work on this challenging part. I should really abandon that and work
on TUI + PTAGS y basta.

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

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

The secmark "one user" policy

[Casey Schaufler]

On 6/26/2017 12:54 AM, Jos? Bollo wrote:
> On Sun, 25 Jun 2017 11:05:24 -0700
> Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>> On 6/25/2017 2:41 AM, James Morris wrote:
>>> On Fri, 23 Jun 2017, Casey Schaufler wrote:
>>>  
>>>> On 6/22/2017 8:12 PM, James Morris wrote:  
>>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote:
>>>>>  
>>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not
>>>>>> the goal so much as the test case. MAC was the coolest possible
>>>>>> technology in 1990. We've implemented it. I don't see anyone
>>>>>> doing a new MAC implementation. I *do* see security modules that
>>>>>> implement other security models in the pipeline. Some of these
>>>>>> need to maintain state, which means using security blobs in the
>>>>>> LSM architecture. Some of these models will want to use secmarks
>>>>>> to implement socket based controls.  
>>>>> Where are these LSMs and where are the discussions about their
>>>>> LSM API needs?   
>>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
>>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
>>>> have all been discussed on the LSM list in the past two years.  
>>> Which of these need to use secmarks to implement socket controls?  
>> PTAGS doesn't, but will need to do so to be complete.
> Hello Casey,
>
> The very sleepy PTAGS is suddently awaken (at least one ear :^).
>
> In my mind, PTAGS is dealing with processes. When packets are filtered,
> the only revelent info is the emitter process. At the moment, I don't
> see valuable situation where mediation isn't explicit thus faking origin
> isn't needed.
>
> So I would really like to understand your vision here. What do I miss?

My thought is that getting the tags of the process on the other
end of a network connection seems like a valuable facility.

>
> Best regards
> Jos?
>
> PS. I reworked the TUI (Task Unic Id) and have something valuable now.
> I haven't submitted it because I wanted to include a kind of FS library
> to provide /proc like features. But it is a nightmare to find a minute
> to work on this challenging part. I should really abandon that and work
> on TUI + PTAGS y basta.
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-security-module" in the body of a message to
>> majordomo at vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

The secmark "one user" policy

[José Bollo]

On Mon, 26 Jun 2017 08:10:44 -0700
Casey Schaufler <casey@schaufler-ca.com> wrote:

> On 6/26/2017 12:54 AM, Jos? Bollo wrote:
> > On Sun, 25 Jun 2017 11:05:24 -0700
> > Casey Schaufler <casey@schaufler-ca.com> wrote:
> >  
> >> On 6/25/2017 2:41 AM, James Morris wrote:  
> >>> On Fri, 23 Jun 2017, Casey Schaufler wrote:
> >>>    
> >>>> On 6/22/2017 8:12 PM, James Morris wrote:    
> >>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote:
> >>>>>    
> >>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is
> >>>>>> not the goal so much as the test case. MAC was the coolest
> >>>>>> possible technology in 1990. We've implemented it. I don't see
> >>>>>> anyone doing a new MAC implementation. I *do* see security
> >>>>>> modules that implement other security models in the pipeline.
> >>>>>> Some of these need to maintain state, which means using
> >>>>>> security blobs in the LSM architecture. Some of these models
> >>>>>> will want to use secmarks to implement socket based
> >>>>>> controls.    
> >>>>> Where are these LSMs and where are the discussions about their
> >>>>> LSM API needs?     
> >>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
> >>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
> >>>> have all been discussed on the LSM list in the past two
> >>>> years.    
> >>> Which of these need to use secmarks to implement socket
> >>> controls?    
> >> PTAGS doesn't, but will need to do so to be complete.  
> > Hello Casey,
> >
> > The very sleepy PTAGS is suddently awaken (at least one ear :^).
> >
> > In my mind, PTAGS is dealing with processes. When packets are
> > filtered, the only revelent info is the emitter process. At the
> > moment, I don't see valuable situation where mediation isn't
> > explicit thus faking origin isn't needed.
> >
> > So I would really like to understand your vision here. What do I
> > miss?  
> 
> My thought is that getting the tags of the process on the other
> end of a network connection seems like a valuable facility.

I can see 3 objections: (1) secmark isn't really interesting for
transmitting hierachical strings; (2) maintaining 2 or more remotes in
a coherent state implies more than implicit assumptions; (3) never
trust the network.

Best regards
I sign Jos? but is it me or just someone in the middle that wrote it?

> 
> >
> > Best regards
> > Jos?
> >
> > PS. I reworked the TUI (Task Unic Id) and have something valuable
> > now. I haven't submitted it because I wanted to include a kind of
> > FS library to provide /proc like features. But it is a nightmare to
> > find a minute to work on this challenging part. I should really
> > abandon that and work on TUI + PTAGS y basta.
> >  
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-security-module" in the body of a message to
> >> majordomo at vger.kernel.org More majordomo info at
> >> http://vger.kernel.org/majordomo-info.html  
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-security-module" in the body of a message to
> > majordomo at vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in the body of a message to
> majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

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

The secmark "one user" policy

[Paul Moore]

On Tue, Jun 27, 2017 at 6:51 AM, Jos? Bollo <jobol@nonadev.net> wrote:
> On Mon, 26 Jun 2017 08:10:44 -0700
> Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>> On 6/26/2017 12:54 AM, Jos? Bollo wrote:
>> > On Sun, 25 Jun 2017 11:05:24 -0700
>> > Casey Schaufler <casey@schaufler-ca.com> wrote:
>> >
>> >> On 6/25/2017 2:41 AM, James Morris wrote:
>> >>> On Fri, 23 Jun 2017, Casey Schaufler wrote:
>> >>>
>> >>>> On 6/22/2017 8:12 PM, James Morris wrote:
>> >>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote:
>> >>>>>
>> >>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is
>> >>>>>> not the goal so much as the test case. MAC was the coolest
>> >>>>>> possible technology in 1990. We've implemented it. I don't see
>> >>>>>> anyone doing a new MAC implementation. I *do* see security
>> >>>>>> modules that implement other security models in the pipeline.
>> >>>>>> Some of these need to maintain state, which means using
>> >>>>>> security blobs in the LSM architecture. Some of these models
>> >>>>>> will want to use secmarks to implement socket based
>> >>>>>> controls.
>> >>>>> Where are these LSMs and where are the discussions about their
>> >>>>> LSM API needs?
>> >>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot,
>> >>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A.
>> >>>> have all been discussed on the LSM list in the past two
>> >>>> years.
>> >>> Which of these need to use secmarks to implement socket
>> >>> controls?
>> >> PTAGS doesn't, but will need to do so to be complete.
>> > Hello Casey,
>> >
>> > The very sleepy PTAGS is suddently awaken (at least one ear :^).
>> >
>> > In my mind, PTAGS is dealing with processes. When packets are
>> > filtered, the only revelent info is the emitter process. At the
>> > moment, I don't see valuable situation where mediation isn't
>> > explicit thus faking origin isn't needed.
>> >
>> > So I would really like to understand your vision here. What do I
>> > miss?
>>
>> My thought is that getting the tags of the process on the other
>> end of a network connection seems like a valuable facility.
>
> I can see 3 objections: (1) secmark isn't really interesting for
> transmitting hierachical strings; (2) maintaining 2 or more remotes in
> a coherent state implies more than implicit assumptions; (3) never
> trust the network.

A point of clarification: the secmark labels are not communicated
across the network, they are assigned to packets based on the local
netfilter configuration.

A simple example with SELinux/secmark:

 # iptables -t mangle -A INPUT --src 192.168.0.16 \
   -p tcp --dport 22 -j SECMARK \
   --selctx system_u:object_r:foo_ssh_packet_t:s0

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

The secmark "one user" policy

[James Morris]

On Thu, 22 Jun 2017, John Johansen wrote:

> I don't see why not. The container could be built expecting smack
> labeling, selinux applies 1 or just a few labels to the whole
> container, and accesses within the container are mediated fine grained
> with smack.

This would require that all LSM-tagged objects and subjects be namespaced, 
correct?  If there is some way that a mediation happens across the 
container boundary, things could get confusing (e.g. Smack policy not 
seeming to allow things which SELinux is in fact denying).

Note also that LSM and namespaces are not abstracted in identical ways, so 
we would need to know what it it means for LSM policy when say networking 
is namespaced but not mounts.  Or how to deal with shared subtrees.

Namespacing of LSM is probably the more fundamental issue to be resolved.


> A little more speculatively another potential example would be an LSM
> doing a personal firewalls around individual applications. Its really
> very similar to the snappy/flatpak sandboxing of apps but maybe
> someone wants that with out the additional baggage of a bigger LSM.
> Whether it would ever get in upstream is a separate question.

Landlock shows promise here, and stacking it inside one of the major MAC 
LSMs seems to make sense.



-- 
James Morris
<jmorris@namei.org>

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

The secmark "one user" policy

[John Johansen]

On 06/29/2017 02:10 AM, James Morris wrote:
> On Thu, 22 Jun 2017, John Johansen wrote:
> 
>> I don't see why not. The container could be built expecting smack
>> labeling, selinux applies 1 or just a few labels to the whole
>> container, and accesses within the container are mediated fine grained
>> with smack.
> 
> This would require that all LSM-tagged objects and subjects be namespaced, 
> correct?  If there is some way that a mediation happens across the 
> container boundary, things could get confusing (e.g. Smack policy not 
> seeming to allow things which SELinux is in fact denying).
> 
> Note also that LSM and namespaces are not abstracted in identical ways, so 
> we would need to know what it it means for LSM policy when say networking 
> is namespaced but not mounts.  Or how to deal with shared subtrees.
> 
> Namespacing of LSM is probably the more fundamental issue to be resolved.
> 

Yes namespacing of LSMs is an open issue that needs to be solved, and
probably would be needed for the selinux, and smack case, or apparmor
system + (selinux/smack container) but would not be needed for the
(selinux/smack system) + apparmor container case. Stacking should be
sufficient today because apparmor internally supports stacking and
namespacing of it self.  ie. system apparmor + container with a
different apparmor policy

With Casey's stacking patches today we can do an selinux host with an
apparmor container by having selinux do regular enforcement and
setting the system apparmor policy to unconfined.  The container is
then setup to use an apparmor policy namespace. Permissions for the
host are determined by selinux and in the container by the
intersection of what is granted by the selinux system policy and what
is allowed by the apparmor policy in the container.

But we run into problems with networking as soon as apparmor's support
for secmark lands.

> 
>> A little more speculatively another potential example would be an LSM
>> doing a personal firewalls around individual applications. Its really
>> very similar to the snappy/flatpak sandboxing of apps but maybe
>> someone wants that with out the additional baggage of a bigger LSM.
>> Whether it would ever get in upstream is a separate question.
> 
> Landlock shows promise here, and stacking it inside one of the major MAC 
> LSMs seems to make sense.
> 

agreed Landlock is promising here


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