Re: Security modules and sending signals within the same process

[Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

* Casey Schaufler:

> On 11/30/2018 7:14 AM, Florian Weimer wrote:
>> Is it guaranteed that tasks in the same thread group can always send
>> signals to each other, irrespective of their respective credentials
>> structs?
>
> No. An LSM may chose to disallow this based on just about any
> criteria it desires.

Hmm.

>> It's not clear to me whether this is always possible based on the
>> security_task_kill implementations I've examined.
>
> SELinux, Smack and AppArmor make their decisions based on
> the task_struct credential, so if it's possible to change
> the LSM attributes at the task granularity, it's possible
> to have a process that can't always talk to itself.

Yes, we already have this today for LSM attributes.  We only paper over
this for the UIDs/GIDs, using a really awkward mechanism.  Maybe we will
get rid of that one day, when the kernel supports a proper per-process
attribute, but I don't count on it.

>> I want to support per-thread setresuid/setresgid,
>
> That's pretty dangerous in its own right. Effectively
> the process containing the threads has multiple UIDs.
> That complicates the DAC model significantly.

Sure.  But I think it's better to do this explicitly in glibc, rather
than file server authors calling the system calls directly.  And it only
exposes what the kernel does anyway.

Thanks,
Florian

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor