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