From: Florian Weimer <fweimer@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org,
selinux@vger.kernel.org, linux-api@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: Security modules and sending signals within the same process
Date: Fri, 30 Nov 2018 19:00:21 +0100 [thread overview]
Message-ID: <87k1kuqwcq.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <2c3e813c-f56a-3354-1299-30b0646f40e1@schaufler-ca.com> (Casey Schaufler's message of "Fri, 30 Nov 2018 09:54:44 -0800")
* 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
next prev parent reply other threads:[~2018-11-30 18:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 15:14 Security modules and sending signals within the same process Florian Weimer
2018-11-30 16:02 ` Stephen Smalley
2018-12-11 10:42 ` Florian Weimer
2018-11-30 17:54 ` Casey Schaufler
2018-11-30 18:00 ` Florian Weimer [this message]
2018-11-30 23:38 ` [apparmor] " John Johansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1kuqwcq.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=apparmor@lists.ubuntu.com \
--cc=arnd@arndb.de \
--cc=casey@schaufler-ca.com \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).