Security modules and sending signals within the same process

[Florian Weimer]

* 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