Re: [PATCH v13 0/9] LSM: Multiple concurrent LSMs

[Kees Cook]

On Thu, Apr 25, 2013 at 1:21 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> On 4/25/2013 12:14 PM, Paul Moore wrote:
>> On Thursday, April 25, 2013 11:09:23 AM Casey Schaufler wrote:
>>> On 4/25/2013 8:01 AM, Paul Moore wrote:
>>>> On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
>>>>> On 4/24/2013 4:00 PM, John Johansen wrote:
>>>>>> On 04/24/2013 02:15 PM, Paul Moore wrote:
>>>>>>> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
>>>> ...
>>>>
>>>>>>>> An interesting aside that may be relevant is that the error
>>>>>>>> condition behavior makes it advisable to have the LSM you care
>>>>>>>> about most go last. If the networking components were strictly
>>>>>>>> FCFS you might have to chose an ordering you might not want for
>>>>>>>> other reasons.
>>>>>>> Well, maybe not ... I think.  If we take a FCFS approach to the network
>>>>>>> controls then only one LSM is really ever going to throw an error on
>>>>>>> the
>>>>>>> network hooks, yes?
>>>>> You set up the order you want to get the networking handled
>>>>> correctly and you could get filesystem hooks in the wrong order.
>>>>> Not that that really ought to be a problem, but there are wonky
>>>>> admin tools out there.
>>>> I don't quite follow; can you be a bit more explicit about getting the
>>>> filesystem hooks in the wrong order?
>>> Let's assume that there's a case for the stat() system call that
>>> would get EPERM from SELinux and EACCES from Smack. A carefully
>>> crafted admin tool might take different actions based on the return
>>> code. If Smack ahead of SELinux in the list the tool will respond
>>> one way, whereas if SELinux is ahead it will behave the other way.
>>>
>>> If this tool came with Fedora it will likely expect the SELinux
>>> error code. Thus, it will be somewhat important that Smack precede
>>> SELinux in the LSM ordering. That will grant Smack the NetLabel
>>> component. If you want SELinux to use NetLabel you'll have to
>>> explicitly configure that.
>>>
>>> It's probably not going to be an issue that often. Making the
>>> ordering implications clear to those who may be affected by them
>>> is probably the best choice and biggest challenge. It would be
>>> nice to keep them to a minimum. I fear some future LSM author
>>> getting clever with error codes and demanding the ultimate
>>> position in all cases.
>> I guess this begs the question, why does the stacking take the return value
>> from the last LSM and not the first?  I'm sure there was a design decision
>> made here, I'm just curious about the reasons why.
>
> The hook loop is trivially simpler if you return the last error than
> if you return the first error:
>
>         if (thisrc)
>                 rc = thisrc;
>
> vs
>
>         if (thisrc && !rc)
>                 rc = thisrc;
>
> If I had decided to do shortcutting (return on first failure) it
> would be a different story.
>
>> To me, and maybe I'm the odd one out here,
>
> I don't know that you're the only odd one here. :)
>
>> but I would think that the first
>> LSM in the stacking order should get precedence;
>
> My desire and intent is that to the extent possible there should
> be no "principle" LSM. The choice of last error is purely driven
> by the fact that it's the easiest thing to do.
>
>> this is why I'm pushing for a
>> FCFS for the network controls.  If it turns out that the stacking patches give
>> preference for the last LSM in the stacking order (I think this will always
>> seem backwards to me) then we should probably give the networking controls to
>> the last LSM.
>
> I actually think that FCFS for networking services and last error code
> hits closest to the sweet spot. "security=yama,smack,selinux" would give
> NetLabel to Smack and xfrm and secmark to SELinux. It would also give
> SELinux error returns in cases where there are multiple reasons for
> denial. Since SELinux has a more sophisticated runtime environment than
> Smack this is likely to make Fedora (for example) happier.

Yeah, this seems good to me too.

-Kees

--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/