* Currently the kernel is interpreting reading the link file on /proc/PID/exe as sys_ptrace for a different UID.
@ 2012-02-13 21:49 Daniel J Walsh
2012-02-13 23:09 ` Stephen Smalley
0 siblings, 1 reply; 5+ messages in thread
From: Daniel J Walsh @ 2012-02-13 21:49 UTC (permalink / raw)
To: Stephen Smalley, Eric Paris, SELinux
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk85hYIACgkQrlYvE4MpobPnsACcDXrEipv+rkdDa1/E4TwQdrtj
z9IAn2yCwDDdAvUIxiSugzMJQZUzswJ1
=Tfwm
-----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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Currently the kernel is interpreting reading the link file on /proc/PID/exe as sys_ptrace for a different UID.
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
0 siblings, 1 reply; 5+ messages in thread
From: Stephen Smalley @ 2012-02-13 23:09 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Stephen Smalley, Eric Paris, SELinux
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Currently the kernel is interpreting reading the link file on /proc/PID/exe as sys_ptrace for a different UID.
2012-02-13 23:09 ` Stephen Smalley
@ 2012-02-14 13:57 ` Daniel J Walsh
2012-02-21 20:36 ` Stephen Smalley
0 siblings, 1 reply; 5+ messages in thread
From: Daniel J Walsh @ 2012-02-14 13:57 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Stephen Smalley, Eric Paris, SELinux
-----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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Currently the kernel is interpreting reading the link file on /proc/PID/exe as sys_ptrace for a different UID.
2012-02-14 13:57 ` Daniel J Walsh
@ 2012-02-21 20:36 ` Stephen Smalley
2012-02-21 21:54 ` Daniel J Walsh
0 siblings, 1 reply; 5+ messages in thread
From: Stephen Smalley @ 2012-02-21 20:36 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Eric Paris, SELinux
On Tue, 2012-02-14 at 08:57 -0500, Daniel J Walsh wrote:
> 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:
> >> 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.
>
> 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.
What you are asking for is a change to the Linux DAC logic, not a change
to SELinux. You can certainly investigate that, but that has to be
taken up on lkml, not here.
--
Stephen Smalley
National Security Agency
--
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Currently the kernel is interpreting reading the link file on /proc/PID/exe as sys_ptrace for a different UID.
2012-02-21 20:36 ` Stephen Smalley
@ 2012-02-21 21:54 ` Daniel J Walsh
0 siblings, 0 replies; 5+ messages in thread
From: Daniel J Walsh @ 2012-02-21 21:54 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Eric Paris, SELinux
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/21/2012 03:36 PM, Stephen Smalley wrote:
> On Tue, 2012-02-14 at 08:57 -0500, Daniel J Walsh wrote:
>> 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:
>>>> 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.
>>
>> 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.
>
> What you are asking for is a change to the Linux DAC logic, not a
> change to SELinux. You can certainly investigate that, but that
> has to be taken up on lkml, not here.
>
As much as I dislike it, I am just adding back in the sys_ptrace
access. Since the ptrace will still be blocked, it is not as big a deal.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9EEn8ACgkQrlYvE4MpobMX1wCgtZlSgdv4nEkAajbc7zNWVAF/
Y0IAoOGnFyLaxrsXb6BLWlX63BUemgWu
=Ts9D
-----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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-02-21 21:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2012-02-21 20:36 ` Stephen Smalley
2012-02-21 21:54 ` Daniel J Walsh
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.