All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Stephen Smalley <stephen.smalley@gmail.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Eric Paris <eparis@redhat.com>, SELinux <selinux@tycho.nsa.gov>
Subject: Re: Currently the kernel is interpreting reading the link file on /proc/PID/exe as sys_ptrace for a different UID.
Date: Tue, 14 Feb 2012 08:57:31 -0500	[thread overview]
Message-ID: <4F3A684B.6010009@redhat.com> (raw)
In-Reply-To: <CAB9W1A3SHFQ-YQAUDyN=wCx0x3PQvrvmSo90_VzUDd-m5-ZTiw@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/13/2012 06:09 PM, Stephen Smalley wrote:
> On Mon, Feb 13, 2012 at 1:49 PM, Daniel J Walsh <dwalsh@redhat.com>
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> I believe this should be DAC_READ_SEARCH.
>> 
>> I am trying to prevent all SYS_PTRACE from any domain on the
>> system but certain apps like dbus, consolekit, policykit,
>> systemd-logger and others like to look /proc/PID/exe to report
>> the path of the executable they are communicating with.  This
>> causes lots of sys_ptrace access being required for domains, that
>> I do not believe need it.
>> 
>> They need DAC_READ_SEARCH because they are trying to read content
>> that is owned by a different UID.  The SYS_PTRACE stuff was put
>> in to prevent apps from reading process memory information stored
>> in /proc.
>> 
>> I think this is a bug in the kernel.
> 
> SELinux just mirrors the Linux capability checks.  CAP_SYS_PTRACE
> is applied when the normal DAC check on ptrace fails (i.e.
> different uid).  The SELinux MAC check here is the :process ptrace
> check.  That is what you should focus on - SELinux already
> distinguishes /proc access from ptrace (except for /proc/pid/mem,
> which is viewed as equivalent).  dontaudit :capability sys_ptrace
> where needed, but not :process ptrace.
> 
> 
> -- This message was distributed to subscribers of the selinux
> mailing list. If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov with the words "unsubscribe selinux"
> without quotes as the message.



But I have to allow all these domains capability sys_ptrace then,
since these domains legitimately want to either use an access check
based on the executable of the process or in the case of the
systemd_jounal, want to log it.

If the CAP check on reading a symbolic link in /proc is SYS_PTRACE,
that seems bogus.  If it was reading /proc/pid/mem or any of the other
/proc/pid fields that tell you about the memory, then I agree those
should be SYS_PTRACE.  But this is a DAC_READ_SEARCH check in my opinion.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk86aEoACgkQrlYvE4MpobO0PQCeOICfnYN7KOPFinPDUFGtBWGf
GE4AnibOo/KpJixmKqktQpGZgE2aDbEx
=g2rt
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2012-02-14 13:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-13 21:49 Currently the kernel is interpreting reading the link file on /proc/PID/exe as sys_ptrace for a different UID Daniel J Walsh
2012-02-13 23:09 ` Stephen Smalley
2012-02-14 13:57   ` Daniel J Walsh [this message]
2012-02-21 20:36     ` Stephen Smalley
2012-02-21 21:54       ` Daniel J Walsh

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=4F3A684B.6010009@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=eparis@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=stephen.smalley@gmail.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.