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