Thread (1 message) 1 message, 1 author, 2018-11-30

Re: Security modules and sending signals within the same process

From: Florian Weimer <hidden>
Date: 2018-11-30 18:00:21
Also in: linux-security-module, selinux

* Casey Schaufler:
On 11/30/2018 7:14 AM, Florian Weimer wrote:
quoted
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.
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help