The secmark "one user" policy

[john.johansen@canonical.com (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