All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
	SELinux List <selinux@tycho.nsa.gov>
Subject: Re: Impersonating a process for file creation purposes
Date: Mon, 27 Apr 2015 11:06:42 +0200	[thread overview]
Message-ID: <553DFC22.3050006@redhat.com> (raw)
In-Reply-To: <552FA882.7030604@tycho.nsa.gov>

On 04/16/2015 02:18 PM, Stephen Smalley wrote:

> 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.

We tried this, and strace shows a lot of activity behind the scenes:

3449  open("/sys/fs/selinux/mls", O_RDONLY) = 4
3449  read(4, "1", 19)                  = 1
3449  close(4)                          = 0
3449  futex(0x7fefa9b34820, FUTEX_WAKE_PRIVATE, 2147483647) = 0
3449  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
3449  connect(4, {sa_family=AF_LOCAL,
sun_path="/var/run/setrans/.setrans-unix"}, 110) = -1 ENOENT (No such
file or directory)
3449  close(4)                          = 0
3449  fgetxattr(3, "security.selinux",
"unconfined_u:object_r:user_home_dir_t:s0", 255) = 41
3449  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
3449  connect(4, {sa_family=AF_LOCAL,
sun_path="/var/run/setrans/.setrans-unix"}, 110) = -1 ENOENT (No such
file or directory)
3449  close(4)                          = 0
3449  stat("/sys/fs/selinux/class", {st_mode=S_IFDIR|0555, st_size=0,
...}) = 0
3449  futex(0x7fefa9b3375c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
3449  open("/sys/fs/selinux/class/file/index", O_RDONLY) = 4
3449  read(4, "6", 19)                  = 1
3449  close(4)                          = 0
3449  openat(AT_FDCWD, "/sys/fs/selinux/class/file/perms",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
3449  getdents(4, /* 24 entries */, 32768) = 728
3449  open("/sys/fs/selinux/class/file/perms/.", O_RDONLY|O_CLOEXEC) = 5
3449  fstat(5, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
3449  close(5)                          = 0
3449  open("/sys/fs/selinux/class/file/perms/..", O_RDONLY|O_CLOEXEC) = 5
3449  fstat(5, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
3449  close(5)                          = 0
3449  open("/sys/fs/selinux/class/file/perms/audit_access",
O_RDONLY|O_CLOEXEC) = 5
3449  fstat(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
3449  read(5, "22", 19)                 = 2
3449  close(5)                          = 0
3449  open("/sys/fs/selinux/class/file/perms/open", O_RDONLY|O_CLOEXEC) = 5
3449  fstat(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
3449  read(5, "21", 19)                 = 2
3449  close(5)                          = 0

And so on.

We use this code sequence:

    if (getpidcon(pid, &srccon) < 0)
    {
        perror_msg("getpidcon(%d)", pid);
        return -1;
    }

    if (fgetfilecon(dirfd(proc_cwd), &dstcon) < 0)
    {
        perror_msg("getfilecon(%s)", user_pwd);
        return -1;
    }

    if (security_compute_create(srccon, dstcon,
string_to_security_class("file"), &newcon) < 0)
    {
        perror_msg("security_compute_create()");
        return -1;
    }

    if (setfscreatecon(newcon) < 0)
    {
        perror_msg("setfscreatecon(newcon)");
        return -1;
    }

This happens after switching to the other user ID (not root), and I
think we should run the preparatory steps (everything before the call to
setfscreatecon) as root.

Is there are supported way to get something leaner?  Is it really
necessary to get setrans involved?  Can't we just copy the kernel
context without translating it back and forth?

-- 
Florian Weimer / Red Hat Product Security

  parent reply	other threads:[~2015-04-27  9:06 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
2015-04-16 12:34   ` Florian Weimer
2015-04-27  9:06   ` Florian Weimer [this message]
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=553DFC22.3050006@redhat.com \
    --to=fweimer@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --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.