All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	selinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org,
	linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Subject: Re: Security modules and sending signals within the same process
Date: Tue, 11 Dec 2018 11:42:20 +0100	[thread overview]
Message-ID: <87d0q8z6nn.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <e754fa24-899b-f77e-f226-0f070ebad132-+05T5uksL2qpZYMLLGbcSA@public.gmane.org> (Stephen Smalley's message of "Fri, 30 Nov 2018 11:02:15 -0500")

* Stephen Smalley:

> Looks like commit 065add3941bd ("signals: check_kill_permission():
> don't check creds if same_thread_group()") skipped the uid-based
> checks if the sender and target were in the same thread group, but not
> the security hook call.  One could argue that the security hook call
> ought to be skipped in that case as well using the same rationale
> given in that commit.  Nothing appears to guarantee the property you
> state above for security_task_kill implementations, although none of
> the in-tree users are based on uids or gids so setresuid/setresgid
> shouldn't affect them.

Okay, thanks, so it looks like I don't have to do anything special to
support thread cancellation.

Florian

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

WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org,
	selinux@vger.kernel.org, linux-api@vger.kernel.org,
	Arnd Bergmann <arnd@arndb.de>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Security modules and sending signals within the same process
Date: Tue, 11 Dec 2018 11:42:20 +0100	[thread overview]
Message-ID: <87d0q8z6nn.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <e754fa24-899b-f77e-f226-0f070ebad132@tycho.nsa.gov> (Stephen Smalley's message of "Fri, 30 Nov 2018 11:02:15 -0500")

* Stephen Smalley:

> Looks like commit 065add3941bd ("signals: check_kill_permission():
> don't check creds if same_thread_group()") skipped the uid-based
> checks if the sender and target were in the same thread group, but not
> the security hook call.  One could argue that the security hook call
> ought to be skipped in that case as well using the same rationale
> given in that commit.  Nothing appears to guarantee the property you
> state above for security_task_kill implementations, although none of
> the in-tree users are based on uids or gids so setresuid/setresgid
> shouldn't affect them.

Okay, thanks, so it looks like I don't have to do anything special to
support thread cancellation.

Florian

  parent reply	other threads:[~2018-12-11 10:42 UTC|newest]

Thread overview: 12+ 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 15:14 ` Florian Weimer
     [not found] ` <87lg5asilo.fsf-fjB847h8rq0pB0kWxzfTigCJwEvxM/w9@public.gmane.org>
2018-11-30 16:02   ` Stephen Smalley
2018-11-30 16:02     ` Stephen Smalley
     [not found]     ` <e754fa24-899b-f77e-f226-0f070ebad132-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
2018-12-11 10:42       ` Florian Weimer [this message]
2018-12-11 10:42         ` Florian Weimer
2018-11-30 17:54   ` Casey Schaufler
2018-11-30 17:54     ` Casey Schaufler
     [not found]     ` <2c3e813c-f56a-3354-1299-30b0646f40e1-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2018-11-30 18:00       ` Florian Weimer
2018-11-30 18:00         ` Florian Weimer
2018-11-30 23:38       ` John Johansen
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=87d0q8z6nn.fsf@oldenburg2.str.redhat.com \
    --to=fweimer-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org \
    --cc=selinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.