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