On 6/21/2017 4:07 PM, John Johansen wrote:

On 06/21/2017 08:23 AM, Casey Schaufler wrote:

quoted

On 6/21/2017 12:13 AM, James Morris wrote:

quoted

On Tue, 20 Jun 2017, Casey Schaufler wrote:

quoted

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?

quoted

---
* 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