I am trying an experiment of making allow_ptrace boolean actually do something useful.

I am trying an experiment of making allow_ptrace boolean actually do something useful.

[Daniel J Walsh]

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

The idea is, if you turn this boolean off, no domains will be allowed
to sys_ptrace or ptrace.

In doing this, I have noticed that the simplest ps -eZ command
generates an access violation.

allow sysadm_t self:capability sys_ptrace;


# ps
  PID TTY          TIME CMD
 2123 pts/1    00:00:00 sudo
 2127 pts/1    00:00:05 sh
 4095 pts/1    00:00:00 ps
sh-4.2# aud


#============= sysadm_t ==============
allow sysadm_t self:capability sys_ptrace;

To me this looks like we are being too strict on the sys_ptrace
cabability checking, which I believe is a bug in the kernel.


If I go into /proc/PID directory of domain with a different UID, I get
the following, permission denieds:

cat: auxv: Permission denied
cat: cwd: Permission denied
cat: environ: Permission denied
cat: exe: Permission denied
cat: io: Permission denied
cat: maps: Permission denied
cat: numa_maps: Permission denied
cat: pagemap: Permission denied
cat: root: Permission denied
cat: smaps: Permission denied
cat: cwd: Permission denied

Are all these really needed?  Is knowing a processes current working
directory the same as executing

gdb -p PID


???

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

iEYEARECAAYFAk6MfcoACgkQrlYvE4MpobNHggCfQ0grVjr4ewpfSS8v09rBjHCO
2REAnjSbZtLgyHuSixIa3+FlSlQ8nnoz
=K+QE
-----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.

Re: I am trying an experiment of making allow_ptrace boolean actually do something useful.

[Daniel J Walsh]

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

On 10/05/2011 11:54 AM, Daniel J Walsh wrote:
> The idea is, if you turn this boolean off, no domains will be
> allowed to sys_ptrace or ptrace.
> 
> In doing this, I have noticed that the simplest ps -eZ command 
> generates an access violation.
> 
> allow sysadm_t self:capability sys_ptrace;
> 
> 
> # ps PID TTY          TIME CMD 2123 pts/1    00:00:00 sudo 2127
> pts/1    00:00:05 sh 4095 pts/1    00:00:00 ps sh-4.2# aud
> 
> 
> #============= sysadm_t ============== allow sysadm_t
> self:capability sys_ptrace;
> 
> To me this looks like we are being too strict on the sys_ptrace 
> cabability checking, which I believe is a bug in the kernel.
> 
> 
> If I go into /proc/PID directory of domain with a different UID, I
> get the following, permission denieds:
> 
> cat: auxv: Permission denied cat: cwd: Permission denied cat:
> environ: Permission denied cat: exe: Permission denied cat: io:
> Permission denied cat: maps: Permission denied cat: numa_maps:
> Permission denied cat: pagemap: Permission denied cat: root:
> Permission denied cat: smaps: Permission denied cat: cwd:
> Permission denied
> 
> Are all these really needed?  Is knowing a processes current
> working directory the same as executing
> 
> gdb -p PID
> 
> 
> ???
> 
> 
> -- 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.
> 
> 

More info. Turns out ps is looking at all /proc/PID/stat and
/proc/PID/status.  It looks like the avc is created if you cat
/proc/PID/stat, without generating a permission denied.  (I would bet
there are a ton of sys_ptrace allowed or dont audited just because a
root process runs ps.


# clearlogs
# aud
<no matches>
# cat /proc/26041/stat
26041 (kworker/1:0) S 2 0 0 0 -1 2216722528 0 0 0 0 0 105 0 0 20 0 1 0
9433742 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0
18446744073709551615 0 0 17 1 0 0 0 0 0
# aud
allow sysadm_t self:capability sys_ptrace;

- ----
time->Wed Oct  5 12:01:49 2011
type=SYSCALL msg=audit(1317830509.811:148661): arch=c000003e syscall=0
success=yes exit=171 a0=3 a1=2074000 a2=8000 a3=2 items=0 ppid=2127
pid=4312 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts1 ses=4 comm="cat" exe="/bin/cat"
subj=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 key=(null)
<dwalsh> type=AVC msg=audit(1317830509.811:148661): avc:  denied  {
sys_ptrace } for  pid=4312 comm="cat" capability=19
scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
tcontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=capability


Notice no permission denied.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6MgTcACgkQrlYvE4MpobOL7QCg4Cia2T7qeEmQI5dM2EORbP4B
1rkAniEQYiTnpj6EtZc622oxGxaWGEv2
=/gbR
-----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.

Re: I am trying an experiment of making allow_ptrace boolean actually do something useful.

[Eric Paris]

ps uses /proc/[pid]/stat .

/proc/pid/stat ouputs things like the last EIP ESP mm->start and stop
and the stack top IF you have ptrace permissions.  If you don't have
permissions you just get 0's for those fields.

see fs/proc/array.c::do_task_stat()

Should I force some sort of dontaudit all the way down this code path?

-Eric

On Wed, Oct 5, 2011 at 11:54 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The idea is, if you turn this boolean off, no domains will be allowed
> to sys_ptrace or ptrace.
>
> In doing this, I have noticed that the simplest ps -eZ command
> generates an access violation.
>
> allow sysadm_t self:capability sys_ptrace;
>
>
> # ps
>  PID TTY          TIME CMD
>  2123 pts/1    00:00:00 sudo
>  2127 pts/1    00:00:05 sh
>  4095 pts/1    00:00:00 ps
> sh-4.2# aud
>
>
> #============= sysadm_t ==============
> allow sysadm_t self:capability sys_ptrace;
>
> To me this looks like we are being too strict on the sys_ptrace
> cabability checking, which I believe is a bug in the kernel.
>
>
> If I go into /proc/PID directory of domain with a different UID, I get
> the following, permission denieds:
>
> cat: auxv: Permission denied
> cat: cwd: Permission denied
> cat: environ: Permission denied
> cat: exe: Permission denied
> cat: io: Permission denied
> cat: maps: Permission denied
> cat: numa_maps: Permission denied
> cat: pagemap: Permission denied
> cat: root: Permission denied
> cat: smaps: Permission denied
> cat: cwd: Permission denied
>
> Are all these really needed?  Is knowing a processes current working
> directory the same as executing
>
> gdb -p PID
>
>
> ???
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6MfcoACgkQrlYvE4MpobNHggCfQ0grVjr4ewpfSS8v09rBjHCO
> 2REAnjSbZtLgyHuSixIa3+FlSlQ8nnoz
> =K+QE
> -----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.
>


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

Re: I am trying an experiment of making allow_ptrace boolean actually do something useful.

[Daniel J Walsh]

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

On 10/05/2011 12:16 PM, Eric Paris wrote:
> ps uses /proc/[pid]/stat .
> 
> /proc/pid/stat ouputs things like the last EIP ESP mm->start and
> stop and the stack top IF you have ptrace permissions.  If you
> don't have permissions you just get 0's for those fields.
> 
> see fs/proc/array.c::do_task_stat()
> 
> Should I force some sort of dontaudit all the way down this code
> path?
> 
> -Eric
> 
> On Wed, Oct 5, 2011 at 11:54 AM, Daniel J Walsh <dwalsh@redhat.com>
> wrote: The idea is, if you turn this boolean off, no domains will
> be allowed to sys_ptrace or ptrace.
> 
> In doing this, I have noticed that the simplest ps -eZ command 
> generates an access violation.
> 
> allow sysadm_t self:capability sys_ptrace;
> 
> 
> # ps PID TTY          TIME CMD 2123 pts/1    00:00:00 sudo 2127
> pts/1    00:00:05 sh 4095 pts/1    00:00:00 ps sh-4.2# aud
> 
> 
> #============= sysadm_t ============== allow sysadm_t
> self:capability sys_ptrace;
> 
> To me this looks like we are being too strict on the sys_ptrace 
> cabability checking, which I believe is a bug in the kernel.
> 
> 
> If I go into /proc/PID directory of domain with a different UID, I
> get the following, permission denieds:
> 
> cat: auxv: Permission denied cat: cwd: Permission denied cat:
> environ: Permission denied cat: exe: Permission denied cat: io:
> Permission denied cat: maps: Permission denied cat: numa_maps:
> Permission denied cat: pagemap: Permission denied cat: root:
> Permission denied cat: smaps: Permission denied cat: cwd:
> Permission denied
> 
> Are all these really needed?  Is knowing a processes current
> working directory the same as executing
> 
> gdb -p PID
> 
> 
> ???
> 
>> 
>> -- 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.
>> 
> 
> 
> -- 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.
> 
> 

Grepping through fedora policy I see 21 domains with dontaudit
capability sys_ptrace and another 41 with allow rules.

Seems to me most of these could be eliminated if we just allowed ps -e
to work without generating an AVC.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6Mi4YACgkQrlYvE4MpobPXJwCfYn9GnqFpn08v6VzqPFuIYZnt
1NkAoLN3jFbEq3PmOFggIXPyvwVTmux7
=N4WZ
-----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.

Re: I am trying an experiment of making allow_ptrace boolean actually do something useful.

[Stephen Smalley]

On Wed, 2011-10-05 at 11:54 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The idea is, if you turn this boolean off, no domains will be allowed
> to sys_ptrace or ptrace.
> 
> In doing this, I have noticed that the simplest ps -eZ command
> generates an access violation.
> 
> allow sysadm_t self:capability sys_ptrace;
> 
> 
> # ps
>   PID TTY          TIME CMD
>  2123 pts/1    00:00:00 sudo
>  2127 pts/1    00:00:05 sh
>  4095 pts/1    00:00:00 ps
> sh-4.2# aud
> 
> 
> #============= sysadm_t ==============
> allow sysadm_t self:capability sys_ptrace;
> 
> To me this looks like we are being too strict on the sys_ptrace
> cabability checking, which I believe is a bug in the kernel.
> 
> 
> If I go into /proc/PID directory of domain with a different UID, I get
> the following, permission denieds:
> 
> cat: auxv: Permission denied
> cat: cwd: Permission denied
> cat: environ: Permission denied
> cat: exe: Permission denied
> cat: io: Permission denied
> cat: maps: Permission denied
> cat: numa_maps: Permission denied
> cat: pagemap: Permission denied
> cat: root: Permission denied
> cat: smaps: Permission denied
> cat: cwd: Permission denied
> 
> Are all these really needed?  Is knowing a processes current working
> directory the same as executing
> 
> gdb -p PID
> 
> 
> ???

With modern kernels, SELinux makes a distinction in its permission
checks for ptrace vs /proc/pid but the DAC/capability checks do not.
For SELinux, we check :file read access for most /proc/pid files, and
only check :process ptrace on specific /proc/pid nodes (originally
only /proc/pid/mem, but I see that viro expanded it
to /proc/pid/{syscall, stack, personality} as well; not sure whether
that is justified or if it should just use PTRACE_MODE_READ there as
well).  So you'll see sys_ptrace capability denials but shouldn't
see :process ptrace denials from running ps these days.  Older kernels
would trigger :process ptrace denials from ps due to environ, but that
was switched over to PTRACE_MODE_READ and only triggers :file read now.

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

Re: I am trying an experiment of making allow_ptrace boolean actually do something useful.

[Eric Paris]

On Wed, Oct 5, 2011 at 1:23 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2011-10-05 at 11:54 -0400, Daniel J Walsh wrote:

> With modern kernels, SELinux makes a distinction in its permission
> checks for ptrace vs /proc/pid but the DAC/capability checks do not.
> For SELinux, we check :file read access for most /proc/pid files, and
> only check :process ptrace on specific /proc/pid nodes (originally
> only /proc/pid/mem, but I see that viro expanded it
> to /proc/pid/{syscall, stack, personality} as well; not sure whether
> that is justified or if it should just use PTRACE_MODE_READ there as
> well).  So you'll see sys_ptrace capability denials but shouldn't
> see :process ptrace denials from running ps these days.  Older kernels
> would trigger :process ptrace denials from ps due to environ, but that
> was switched over to PTRACE_MODE_READ and only triggers :file read now.

Everything you say is true.  But I'm having trouble deciding best way
to deal with the CAPABILITY__SYS_PTRACE denials that pop out of the
use of /proc/pid/stat when run by a process that has CAP_SYS_PTRACE.
/proc/pid/stat works just fine even if this permission is not granted,
but we get a denial.  We could dontaudit all of them.  Or maybe I
could look for some way to make the check in __ptrace_may_access use
the dontaudit version of the capability checks.  I'm leaning for that
way, but don't know....

-Eric


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

Re: I am trying an experiment of making allow_ptrace boolean actually do something useful.

[Stephen Smalley]

On Wed, 2011-10-05 at 13:47 -0400, Eric Paris wrote:
> On Wed, Oct 5, 2011 at 1:23 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Wed, 2011-10-05 at 11:54 -0400, Daniel J Walsh wrote:
> 
> > With modern kernels, SELinux makes a distinction in its permission
> > checks for ptrace vs /proc/pid but the DAC/capability checks do not.
> > For SELinux, we check :file read access for most /proc/pid files, and
> > only check :process ptrace on specific /proc/pid nodes (originally
> > only /proc/pid/mem, but I see that viro expanded it
> > to /proc/pid/{syscall, stack, personality} as well; not sure whether
> > that is justified or if it should just use PTRACE_MODE_READ there as
> > well).  So you'll see sys_ptrace capability denials but shouldn't
> > see :process ptrace denials from running ps these days.  Older kernels
> > would trigger :process ptrace denials from ps due to environ, but that
> > was switched over to PTRACE_MODE_READ and only triggers :file read now.
> 
> Everything you say is true.  But I'm having trouble deciding best way
> to deal with the CAPABILITY__SYS_PTRACE denials that pop out of the
> use of /proc/pid/stat when run by a process that has CAP_SYS_PTRACE.
> /proc/pid/stat works just fine even if this permission is not granted,
> but we get a denial.  We could dontaudit all of them.  Or maybe I
> could look for some way to make the check in __ptrace_may_access use
> the dontaudit version of the capability checks.  I'm leaning for that
> way, but don't know....

I assume you want to pass a flag from do_task_stat() to
ptrace_may_access() or introduce a ptrace_may_access_noaudit() interface
that it can use, so that you only turn off auditing in that particular
case?

I'm ok with that.  But if he wants to be able to remove dontaudit rules
for :process ptrace as well, then we need to make sure that we only
check it for actual ptrace(2) or equivalent (/proc/pid/mem falling into
the latter category).  So unless there is some particular
rationale, /proc/pid/{syscall, stack, personality} should likely be
using PTRACE_MODE_READ instead.

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