From: Stephen Smalley <sds@tycho.nsa.gov>
To: Florian Weimer <fweimer@redhat.com>,
SELinux List <selinux@tycho.nsa.gov>
Subject: Re: Impersonating a process for file creation purposes
Date: Thu, 16 Apr 2015 08:18:10 -0400 [thread overview]
Message-ID: <552FA882.7030604@tycho.nsa.gov> (raw)
In-Reply-To: <552F80C8.9060809@redhat.com>
On 04/16/2015 05:28 AM, Florian Weimer wrote:
> The ABRT coredump handler has code to emulate default core file creation
> (as if no such pipe-based handler was installed). The handler runs in a
> separate process, initially as root. Currently, the handler just
> switches effective IDs and creates the file. This does not replicate
> the SELinux context of the zombie process.
Pardon me for asking, but why does it include this code for emulating
default core file creation, versus just letting the kernel directly
handle it?
> Is there a way to do that? Is there some recommended way to inherit
> all the security-related process attributes?
Technically it could use setcon() if allowed by policy but I wouldn't
really recommend it. You'd have to allow it to dyntransition to any
domain for any potential process you want it to be able to dump, at
which point it could assume any of the permissions of any of those
processes at will. Not so great if there is ever a vulnerability in
ABRT itself. Plus any other process in the same context would be able
to act on the handler at that point as they would then be in the same
context.
It could also compute the context in which the file would be created by
the zombie by calling security_compute_create() with the context of the
zombie process, the context of the directory into which it is writing
the core dump file, and string_to_security_class("file") as its
arguments, and then pass the resulting context returned by that call to
setfscreatecon() prior to creating the core dump file and then call
setfscreatecon(NULL) afterward; this will create the core dump file in
that context. That seems more suited to your scenario.
next prev parent reply other threads:[~2015-04-16 12:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 9:28 Impersonating a process for file creation purposes Florian Weimer
2015-04-16 12:18 ` Stephen Smalley [this message]
2015-04-16 12:34 ` Florian Weimer
2015-04-27 9:06 ` Florian Weimer
2015-04-27 13:27 ` Stephen Smalley
2015-04-27 14:20 ` Stephen Smalley
2015-04-16 18:06 ` Daniel J Walsh
2015-04-20 14:05 ` Florian Weimer
2015-04-28 17:12 ` Miroslav Grepl
2015-04-28 17:19 ` Florian Weimer
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=552FA882.7030604@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=fweimer@redhat.com \
--cc=selinux@tycho.nsa.gov \
/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.