All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Amnon Shiloh <u3557@miso.sublimeip.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Chris Evans <scarybeasts@gmail.com>,
	David Howells <dhowells@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	u3557@dialix.com.au, security@kernel.org,
	linux-kernel@vger.kernel.org
Subject: PF_NO_SIGSTOP (Was: PT_EXITKILL)
Date: Thu, 8 Nov 2012 13:48:53 +0100	[thread overview]
Message-ID: <20121108124853.GC20917@redhat.com> (raw)
In-Reply-To: <20121108062935.BFF3A592024@miso.sublimeip.com>

On 11/08, Amnon Shiloh wrote:
>
> > > What I wish is that I could request (using "prctl" or whatever):
> > > "If a non-privileged user sends me a SIGSTOP, then let it be converted into...",
> >
> > I hope we won't do this ;) But I am not going to argue if you convince
> > other people.
> >
> > To me it would be better to simply allow to catch SIGSTOP, but I hope
> > we won't do this too.
>
> I don't think anyone should seriously contemplate catching SIGSTOP -
> that would break so many applications, including mine.
>
> Now about "convincing", I have that application that really needs this
> feature, and I believe that others may be in the same predicament, which is:
>
> 1. The application is a SUID-root service, available to ordinary users.
> 2. Users who started this application are allowed at any time to signal
>    or kill their instance(s) of this application.

Is this the only reason why this service keeps its original real-UID?
(see below)

> 3. It is alright for the application to be killed by SIGKILL.
> 4. The application catches and does something useful and positive with
>    all other signals sent to it by the invoking user, including SIGTSTP,
>    SIGTTIN and SIGTTOU.
> 5. If the application is unpreparedly stopped by SIGSTOP, which it cannot
>    catch, then this may disrupt other instances of this application by
>    other users (including, in my case, on other computers connected with
>    the application by TCP/IP sockets).
>
> What I ask is simple and can be so easily implemented, essentially in
> "kernel/signal.c":
>
> static int check_kill_permission(int sig, struct siginfo *info,
> 				 struct task_struct *t)
> {
> ...
> +	if (sig == SIGSTOP && (t->flags & PF_NO_SIGSTOP) && !capable(CAP_KILL))
                               ^^^^^^^^^^^^^^^^^^^^^^^^
No, this is not enough. At least PF_NO_SIGSTOP should be per-process,
not per-thread. But I agree, it is simpe to implement.

So once again, no need to convince me ;) I try to never argue with
the new features, even if personally I do not really like this idea.
If someone acks your idea I will be happy to help with the patch.


And I have another idea... Not that I like it very much, but it looks
simple and maybe useful.

What if we introduce SA_NOSECURITY? So that if an application does

	sa.sa_flags = SA_NOSECURITY | ...;

	sigaction(SIG, &sa, NULL);

then sys_kill/etc bypasses security checks.

This way your service can run as root and still recieve the signals
from the ordinary users. Yes, except SIGKILL/SIGSTOP.

Oleg.


  parent reply	other threads:[~2012-11-08 12:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20121106152050.GA18218@sergelap>
     [not found] ` <20121106201428.9D72959201A@miso.sublimeip.com>
2012-11-07 15:09   ` PT_EXITKILL (Was: pdeath_signal) Oleg Nesterov
2012-11-08  6:29     ` Amnon Shiloh
2012-11-08 12:37       ` Oleg Nesterov
2012-11-08 13:03         ` Amnon Shiloh
2012-11-18 20:21         ` [PATCH 0/1] ptrace: introduce PTRACE_O_EXITKILL Oleg Nesterov
2012-11-18 20:21           ` [PATCH 1/1] " Oleg Nesterov
2012-11-08 12:48       ` Oleg Nesterov [this message]
2012-11-08 14:05         ` PF_NO_SIGSTOP (Was: PT_EXITKILL) Amnon Shiloh
2012-11-08 12:16     ` PT_EXITKILL (Was: pdeath_signal) Pedro Alves
2012-11-08 12:44       ` Oleg Nesterov
2012-11-08 13:00         ` Pedro Alves

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=20121108124853.GC20917@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=dvlasenk@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=scarybeasts@gmail.com \
    --cc=security@kernel.org \
    --cc=serge.hallyn@canonical.com \
    --cc=torvalds@linux-foundation.org \
    --cc=u3557@dialix.com.au \
    --cc=u3557@miso.sublimeip.com \
    /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.