I think this is a bug in the kernel

I think this is a bug in the kernel

[Daniel J Walsh]

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

https://bugzilla.redhat.com/show_bug.cgi?id=445709	

libvirtd is clearly not ptracing the unconfined_t domain.  It is
problably looking under /proc for some information about the app that is
communicating with it.  It might be reading unconfined_t environment.  I
am not sure, but we generate a ptrace and stop the app from working.  My
only choice is to allow virtd to ptrace unconfined_t processes which is
not a good idea.  This has to be fixes in the kernel.

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

iEYEARECAAYFAkgkVg4ACgkQrlYvE4MpobPCvwCfa/iBjD3h2dFnEDvB39c8db0a
ITAAn1ktC480Tvx6lgx01ufjPNeQGOxC
=7O2c
-----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 think this is a bug in the kernel

[Stephen Smalley]

On Fri, 2008-05-09 at 09:47 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=445709	
> 
> libvirtd is clearly not ptracing the unconfined_t domain.  It is
> problably looking under /proc for some information about the app that is
> communicating with it.  It might be reading unconfined_t environment.  I
> am not sure, but we generate a ptrace and stop the app from working.  My
> only choice is to allow virtd to ptrace unconfined_t processes which is
> not a good idea.  This has to be fixes in the kernel.

We do have an item on the kernel todo list to split up the proc ptrace
checking to let us distinguish between reading process state vs.
manipulating/controlling a process.

However, in this case, I notice that you are not only getting a ptrace
permission check between the processes but also a sys_ptrace capability
check.  That manes that virtd is trying to access /proc private info for
a process with a different set of uids, gids, or capabilities.

Splitting up the SELinux check won't help with that.

I'd suggest taking a harder look at libvirtd to see what it is doing and
whether it can achieve the desired result in a cleaner manner that
requires less privilege.

-- 
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 think this is a bug in the kernel

[Daniel J Walsh]

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

Daniel J Walsh wrote:
| https://bugzilla.redhat.com/show_bug.cgi?id=445709
|
| libvirtd is clearly not ptracing the unconfined_t domain.  It is
| problably looking under /proc for some information about the app that is
| communicating with it.  It might be reading unconfined_t environment.  I
| am not sure, but we generate a ptrace and stop the app from working.  My
| only choice is to allow virtd to ptrace unconfined_t processes which is
| not a good idea.  This has to be fixes in the kernel.
|
| Dan

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

Replying to my own email...

Looks like the kernel has it on its todo list...

~ *  Finer-grained proc checking (so that we don't require full ptrace
permission just to read process state),

Well I think we need to jump the priority here.

User apps seem to be doing things like looking at the remote end of the
socket and checking the environment for special cookies in the case of
consolehelper/policykit.  Or may looking to see where the kerberos
tickets are located.  Whether this is a legitimate use or not, it is
being done.  So we need to handle it.  But I have a real concern about
allowing virtd_t to ptrace unconfined_t process.

Basically in order to allow virtd_t to verify the unconfined_t process
that is trying to communicate with it, we need to allow it to read the
memory of every unconfined_t process on the system.  Not good.

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

iEYEARECAAYFAkgkXNYACgkQrlYvE4MpobOC4ACcChtet42S8Y7ffL0l82Eb4FDM
zJEAn2Kxb9sx2SXP87kTUMvbiIurarH8
=3qY6
-----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 think this is a bug in the kernel

[Stephen Smalley]

On Fri, 2008-05-09 at 10:16 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel J Walsh wrote:
> | https://bugzilla.redhat.com/show_bug.cgi?id=445709
> |
> | libvirtd is clearly not ptracing the unconfined_t domain.  It is
> | problably looking under /proc for some information about the app that is
> | communicating with it.  It might be reading unconfined_t environment.  I
> | am not sure, but we generate a ptrace and stop the app from working.  My
> | only choice is to allow virtd to ptrace unconfined_t processes which is
> | not a good idea.  This has to be fixes in the kernel.
> |
> | Dan
> 
> - --
> 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.
> 
> Replying to my own email...
> 
> Looks like the kernel has it on its todo list...
> 
> ~ *  Finer-grained proc checking (so that we don't require full ptrace
> permission just to read process state),
> 
> Well I think we need to jump the priority here.
> 
> User apps seem to be doing things like looking at the remote end of the
> socket and checking the environment for special cookies in the case of
> consolehelper/policykit.  Or may looking to see where the kerberos
> tickets are located.  Whether this is a legitimate use or not, it is
> being done.

That's decidedly racy and unsafe to do.  They shouldn't do that.

>   So we need to handle it.  But I have a real concern about
> allowing virtd_t to ptrace unconfined_t process.
> 
> Basically in order to allow virtd_t to verify the unconfined_t process
> that is trying to communicate with it, we need to allow it to read the
> memory of every unconfined_t process on the system.  Not good.


-- 
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 think this is a bug in the kernel

[Daniel J Walsh]

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

Stephen Smalley wrote:
| On Fri, 2008-05-09 at 10:16 -0400, Daniel J Walsh wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Daniel J Walsh wrote:
|> | https://bugzilla.redhat.com/show_bug.cgi?id=445709
|> |
|> | libvirtd is clearly not ptracing the unconfined_t domain.  It is
|> | problably looking under /proc for some information about the app
that is
|> | communicating with it.  It might be reading unconfined_t
environment.  I
|> | am not sure, but we generate a ptrace and stop the app from
working.  My
|> | only choice is to allow virtd to ptrace unconfined_t processes which is
|> | not a good idea.  This has to be fixes in the kernel.
|> |
|> | Dan
|>
|> - --
|> 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.
|>
|> Replying to my own email...
|>
|> Looks like the kernel has it on its todo list...
|>
|> ~ *  Finer-grained proc checking (so that we don't require full ptrace
|> permission just to read process state),
|>
|> Well I think we need to jump the priority here.
|>
|> User apps seem to be doing things like looking at the remote end of the
|> socket and checking the environment for special cookies in the case of
|> consolehelper/policykit.  Or may looking to see where the kerberos
|> tickets are located.  Whether this is a legitimate use or not, it is
|> being done.
|
| That's decidedly racy and unsafe to do.  They shouldn't do that.
|
|>   So we need to handle it.  But I have a real concern about
|> allowing virtd_t to ptrace unconfined_t process.
|>
|> Basically in order to allow virtd_t to verify the unconfined_t process
|> that is trying to communicate with it, we need to allow it to read the
|> memory of every unconfined_t process on the system.  Not good.
|
|
I think this is policykit that is triggering it.  And with the advent of
~ /proc/$$/sessionid it will become less racy.

But for now it is what they do.

policykit is looking for a unique identifier to identify the "session"
of the process that is trying to communicate with it.  It then uses
consolekit to determine whether the "session" is on the console as
opposed to logged in via ssh or some other remote application.

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

iEYEARECAAYFAkgkX/8ACgkQrlYvE4MpobMaewCgr5tbkCqKcMJi/KcOwIDiUK9z
NfsAoNsEe4bxOJV8z+bWeRwdPwUDVbTW
=/nnR
-----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 think this is a bug in the kernel

[Stephen Smalley]

On Fri, 2008-05-09 at 10:30 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> | On Fri, 2008-05-09 at 10:16 -0400, Daniel J Walsh wrote:
> |> -----BEGIN PGP SIGNED MESSAGE-----
> |> Hash: SHA1
> |>
> |> Daniel J Walsh wrote:
> |> | https://bugzilla.redhat.com/show_bug.cgi?id=445709
> |> |
> |> | libvirtd is clearly not ptracing the unconfined_t domain.  It is
> |> | problably looking under /proc for some information about the app
> that is
> |> | communicating with it.  It might be reading unconfined_t
> environment.  I
> |> | am not sure, but we generate a ptrace and stop the app from
> working.  My
> |> | only choice is to allow virtd to ptrace unconfined_t processes which is
> |> | not a good idea.  This has to be fixes in the kernel.
> |> |
> |> | Dan
> |>
> |> - --
> |> 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.
> |>
> |> Replying to my own email...
> |>
> |> Looks like the kernel has it on its todo list...
> |>
> |> ~ *  Finer-grained proc checking (so that we don't require full ptrace
> |> permission just to read process state),
> |>
> |> Well I think we need to jump the priority here.
> |>
> |> User apps seem to be doing things like looking at the remote end of the
> |> socket and checking the environment for special cookies in the case of
> |> consolehelper/policykit.  Or may looking to see where the kerberos
> |> tickets are located.  Whether this is a legitimate use or not, it is
> |> being done.
> |
> | That's decidedly racy and unsafe to do.  They shouldn't do that.
> |
> |>   So we need to handle it.  But I have a real concern about
> |> allowing virtd_t to ptrace unconfined_t process.
> |>
> |> Basically in order to allow virtd_t to verify the unconfined_t process
> |> that is trying to communicate with it, we need to allow it to read the
> |> memory of every unconfined_t process on the system.  Not good.
> |
> |
> I think this is policykit that is triggering it.  And with the advent of
> ~ /proc/$$/sessionid it will become less racy.
> 
> But for now it is what they do.
> 
> policykit is looking for a unique identifier to identify the "session"
> of the process that is trying to communicate with it.  It then uses
> consolekit to determine whether the "session" is on the console as
> opposed to logged in via ssh or some other remote application.

So they have two options:
- transfer the session id/cookie in the data of the request (i.e. it's a
capability), or
- extend the kernel the way we did to convey the peer or sender's
security context on a local IPC to the receiver (e.g. getpeercon(3)).

Reading /proc files for that purpose is not the way to go.

-- 
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 think this is a bug in the kernel

[Daniel J Walsh]

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

Stephen Smalley wrote:
| On Fri, 2008-05-09 at 10:30 -0400, Daniel J Walsh wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Stephen Smalley wrote:
|> | On Fri, 2008-05-09 at 10:16 -0400, Daniel J Walsh wrote:
|> |> -----BEGIN PGP SIGNED MESSAGE-----
|> |> Hash: SHA1
|> |>
|> |> Daniel J Walsh wrote:
|> |> | https://bugzilla.redhat.com/show_bug.cgi?id=445709
|> |> |
|> |> | libvirtd is clearly not ptracing the unconfined_t domain.  It is
|> |> | problably looking under /proc for some information about the app
|> that is
|> |> | communicating with it.  It might be reading unconfined_t
|> environment.  I
|> |> | am not sure, but we generate a ptrace and stop the app from
|> working.  My
|> |> | only choice is to allow virtd to ptrace unconfined_t processes
which is
|> |> | not a good idea.  This has to be fixes in the kernel.
|> |> |
|> |> | Dan
|> |>
|> |> - --
|> |> 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.
|> |>
|> |> Replying to my own email...
|> |>
|> |> Looks like the kernel has it on its todo list...
|> |>
|> |> ~ *  Finer-grained proc checking (so that we don't require full ptrace
|> |> permission just to read process state),
|> |>
|> |> Well I think we need to jump the priority here.
|> |>
|> |> User apps seem to be doing things like looking at the remote end
of the
|> |> socket and checking the environment for special cookies in the case of
|> |> consolehelper/policykit.  Or may looking to see where the kerberos
|> |> tickets are located.  Whether this is a legitimate use or not, it is
|> |> being done.
|> |
|> | That's decidedly racy and unsafe to do.  They shouldn't do that.
|> |
|> |>   So we need to handle it.  But I have a real concern about
|> |> allowing virtd_t to ptrace unconfined_t process.
|> |>
|> |> Basically in order to allow virtd_t to verify the unconfined_t process
|> |> that is trying to communicate with it, we need to allow it to read the
|> |> memory of every unconfined_t process on the system.  Not good.
|> |
|> |
|> I think this is policykit that is triggering it.  And with the advent of
|> ~ /proc/$$/sessionid it will become less racy.
|>
|> But for now it is what they do.
|>
|> policykit is looking for a unique identifier to identify the "session"
|> of the process that is trying to communicate with it.  It then uses
|> consolekit to determine whether the "session" is on the console as
|> opposed to logged in via ssh or some other remote application.
|
| So they have two options:
| - transfer the session id/cookie in the data of the request (i.e. it's a
| capability), or
| - extend the kernel the way we did to convey the peer or sender's
| security context on a local IPC to the receiver (e.g. getpeercon(3)).
|
| Reading /proc files for that purpose is not the way to go.
|
You can argue whether what they are doing is right or wrong, this is
afterall just userspace apps trying to get key data about the remote
connection without forcing minor/major changes onto the kernel.  But
whether we like it or not, what they are doing is far less dangerous
then ptrace/sys_ptrace capability will allow them.

Reading /proc/PID/environ or /proc/PID/sessionid  should require
different access then ptrace.

I could also see apps potentially looking at /proc/PID/mounts to see if
the namespace is different.

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

iEYEARECAAYFAkgkYscACgkQrlYvE4MpobN2tACgp4Al5+Yc3KHKZkk8R3BGHkUa
VIAAoKhtVo7p3fMUH0o06uJc3jDJnMwM
=0s0t
-----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 think this is a bug in the kernel

[Stephen Smalley]

On Fri, 2008-05-09 at 10:42 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> | On Fri, 2008-05-09 at 10:30 -0400, Daniel J Walsh wrote:
> |> -----BEGIN PGP SIGNED MESSAGE-----
> |> Hash: SHA1
> |>
> |> Stephen Smalley wrote:
> |> | On Fri, 2008-05-09 at 10:16 -0400, Daniel J Walsh wrote:
> |> |> -----BEGIN PGP SIGNED MESSAGE-----
> |> |> Hash: SHA1
> |> |>
> |> |> Daniel J Walsh wrote:
> |> |> | https://bugzilla.redhat.com/show_bug.cgi?id=445709
> |> |> |
> |> |> | libvirtd is clearly not ptracing the unconfined_t domain.  It is
> |> |> | problably looking under /proc for some information about the app
> |> that is
> |> |> | communicating with it.  It might be reading unconfined_t
> |> environment.  I
> |> |> | am not sure, but we generate a ptrace and stop the app from
> |> working.  My
> |> |> | only choice is to allow virtd to ptrace unconfined_t processes
> which is
> |> |> | not a good idea.  This has to be fixes in the kernel.
> |> |> |
> |> |> | Dan
> |> |>
> |> |> - --
> |> |> 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.
> |> |>
> |> |> Replying to my own email...
> |> |>
> |> |> Looks like the kernel has it on its todo list...
> |> |>
> |> |> ~ *  Finer-grained proc checking (so that we don't require full ptrace
> |> |> permission just to read process state),
> |> |>
> |> |> Well I think we need to jump the priority here.
> |> |>
> |> |> User apps seem to be doing things like looking at the remote end
> of the
> |> |> socket and checking the environment for special cookies in the case of
> |> |> consolehelper/policykit.  Or may looking to see where the kerberos
> |> |> tickets are located.  Whether this is a legitimate use or not, it is
> |> |> being done.
> |> |
> |> | That's decidedly racy and unsafe to do.  They shouldn't do that.
> |> |
> |> |>   So we need to handle it.  But I have a real concern about
> |> |> allowing virtd_t to ptrace unconfined_t process.
> |> |>
> |> |> Basically in order to allow virtd_t to verify the unconfined_t process
> |> |> that is trying to communicate with it, we need to allow it to read the
> |> |> memory of every unconfined_t process on the system.  Not good.
> |> |
> |> |
> |> I think this is policykit that is triggering it.  And with the advent of
> |> ~ /proc/$$/sessionid it will become less racy.
> |>
> |> But for now it is what they do.
> |>
> |> policykit is looking for a unique identifier to identify the "session"
> |> of the process that is trying to communicate with it.  It then uses
> |> consolekit to determine whether the "session" is on the console as
> |> opposed to logged in via ssh or some other remote application.
> |
> | So they have two options:
> | - transfer the session id/cookie in the data of the request (i.e. it's a
> | capability), or
> | - extend the kernel the way we did to convey the peer or sender's
> | security context on a local IPC to the receiver (e.g. getpeercon(3)).
> |
> | Reading /proc files for that purpose is not the way to go.
> |
> You can argue whether what they are doing is right or wrong, this is
> afterall just userspace apps trying to get key data about the remote
> connection without forcing minor/major changes onto the kernel.

Yes, usually you do that either by making it part of the request data (a
capability/token) so that it requires no kernel change or by extending
the kernel to pass additional metadata on IPC as has been done for both
audit and SELinux attributes in the past.

>   But
> whether we like it or not, what they are doing is far less dangerous
> then ptrace/sys_ptrace capability will allow them.
> 
> Reading /proc/PID/environ or /proc/PID/sessionid  should require
> different access then ptrace.

I agree, which is why I originally said we should try to split the
checking so that we can distinguish read-only from control/manipulate
access.

But reading a /proc/pid file for a client process is inherently racy -
you have no guarantee that the info you are reading is for the actual
process that made the connection, e.g. process may connect, fork child,
exec suid program in parent, child retains access to socket, server
looks up /proc/pid data for parent, server sees suid program's
information, child transmits request.

> I could also see apps potentially looking at /proc/PID/mounts to see if
> the namespace is different.

-- 
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 think this is a bug in the kernel

[Daniel J Walsh]

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

Stephen Smalley wrote:
| On Fri, 2008-05-09 at 10:42 -0400, Daniel J Walsh wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Stephen Smalley wrote:
|> | On Fri, 2008-05-09 at 10:30 -0400, Daniel J Walsh wrote:
|> |> -----BEGIN PGP SIGNED MESSAGE-----
|> |> Hash: SHA1
|> |>
|> |> Stephen Smalley wrote:
|> |> | On Fri, 2008-05-09 at 10:16 -0400, Daniel J Walsh wrote:
|> |> |> -----BEGIN PGP SIGNED MESSAGE-----
|> |> |> Hash: SHA1
|> |> |>
|> |> |> Daniel J Walsh wrote:
|> |> |> | https://bugzilla.redhat.com/show_bug.cgi?id=445709
|> |> |> |
|> |> |> | libvirtd is clearly not ptracing the unconfined_t domain.  It is
|> |> |> | problably looking under /proc for some information about the app
|> |> that is
|> |> |> | communicating with it.  It might be reading unconfined_t
|> |> environment.  I
|> |> |> | am not sure, but we generate a ptrace and stop the app from
|> |> working.  My
|> |> |> | only choice is to allow virtd to ptrace unconfined_t processes
|> which is
|> |> |> | not a good idea.  This has to be fixes in the kernel.
|> |> |> |
|> |> |> | Dan
|> |> |>
|> |> |> - --
|> |> |> 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.
|> |> |>
|> |> |> Replying to my own email...
|> |> |>
|> |> |> Looks like the kernel has it on its todo list...
|> |> |>
|> |> |> ~ *  Finer-grained proc checking (so that we don't require full
ptrace
|> |> |> permission just to read process state),
|> |> |>
|> |> |> Well I think we need to jump the priority here.
|> |> |>
|> |> |> User apps seem to be doing things like looking at the remote end
|> of the
|> |> |> socket and checking the environment for special cookies in the
case of
|> |> |> consolehelper/policykit.  Or may looking to see where the kerberos
|> |> |> tickets are located.  Whether this is a legitimate use or not,
it is
|> |> |> being done.
|> |> |
|> |> | That's decidedly racy and unsafe to do.  They shouldn't do that.
|> |> |
|> |> |>   So we need to handle it.  But I have a real concern about
|> |> |> allowing virtd_t to ptrace unconfined_t process.
|> |> |>
|> |> |> Basically in order to allow virtd_t to verify the unconfined_t
process
|> |> |> that is trying to communicate with it, we need to allow it to
read the
|> |> |> memory of every unconfined_t process on the system.  Not good.
|> |> |
|> |> |
|> |> I think this is policykit that is triggering it.  And with the
advent of
|> |> ~ /proc/$$/sessionid it will become less racy.
|> |>
|> |> But for now it is what they do.
|> |>
|> |> policykit is looking for a unique identifier to identify the "session"
|> |> of the process that is trying to communicate with it.  It then uses
|> |> consolekit to determine whether the "session" is on the console as
|> |> opposed to logged in via ssh or some other remote application.
|> |
|> | So they have two options:
|> | - transfer the session id/cookie in the data of the request (i.e.
it's a
|> | capability), or
|> | - extend the kernel the way we did to convey the peer or sender's
|> | security context on a local IPC to the receiver (e.g. getpeercon(3)).
|> |
|> | Reading /proc files for that purpose is not the way to go.
|> |
|> You can argue whether what they are doing is right or wrong, this is
|> afterall just userspace apps trying to get key data about the remote
|> connection without forcing minor/major changes onto the kernel.
|
| Yes, usually you do that either by making it part of the request data (a
| capability/token) so that it requires no kernel change or by extending
| the kernel to pass additional metadata on IPC as has been done for both
| audit and SELinux attributes in the past.
|
|>   But
|> whether we like it or not, what they are doing is far less dangerous
|> then ptrace/sys_ptrace capability will allow them.
|>
|> Reading /proc/PID/environ or /proc/PID/sessionid  should require
|> different access then ptrace.
|
| I agree, which is why I originally said we should try to split the
| checking so that we can distinguish read-only from control/manipulate
| access.
|
| But reading a /proc/pid file for a client process is inherently racy -
| you have no guarantee that the info you are reading is for the actual
| process that made the connection, e.g. process may connect, fork child,
| exec suid program in parent, child retains access to socket, server
| looks up /proc/pid data for parent, server sees suid program's
| information, child transmits request.
|
|> I could also see apps potentially looking at /proc/PID/mounts to see if
|> the namespace is different.
|
I understand, and I believe sessionid is supposed to be frozen and
protect against this.  The only way to change sessionid is via login
programs with a certain capability.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgkZ6oACgkQrlYvE4MpobN1iwCcC+GwHVvBTbQZU+JN0pdyncag
9dUAoNGmI4/4LtZhrWv+POGlQKLgi6+J
=f/hJ
-----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 think this is a bug in the kernel

[Daniel J Walsh]

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

Daniel J Walsh wrote:
| https://bugzilla.redhat.com/show_bug.cgi?id=445709
|
| libvirtd is clearly not ptracing the unconfined_t domain.  It is
| problably looking under /proc for some information about the app that is
| communicating with it.  It might be reading unconfined_t environment.  I
| am not sure, but we generate a ptrace and stop the app from working.  My
| only choice is to allow virtd to ptrace unconfined_t processes which is
| not a good idea.  This has to be fixes in the kernel.
|
| Dan

The policykit developer informs me that

"PolicyKit is trying to resolve the /proc/<pid>/exe link for the
connecting client."


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

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

iEYEARECAAYFAkgoN5EACgkQrlYvE4MpobMb1gCgj+r3ELhTfLWoPYB4RyCl8pHf
fuwAoLZdyFac/547Xn75l6R4TcB5kdHZ
=DzRx
-----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 think this is a bug in the kernel

[Stephen Smalley]

On Mon, 2008-05-12 at 08:26 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel J Walsh wrote:
> | https://bugzilla.redhat.com/show_bug.cgi?id=445709
> |
> | libvirtd is clearly not ptracing the unconfined_t domain.  It is
> | problably looking under /proc for some information about the app that is
> | communicating with it.  It might be reading unconfined_t environment.  I
> | am not sure, but we generate a ptrace and stop the app from working.  My
> | only choice is to allow virtd to ptrace unconfined_t processes which is
> | not a good idea.  This has to be fixes in the kernel.
> |
> | Dan
> 
> The policykit developer informs me that
> 
> "PolicyKit is trying to resolve the /proc/<pid>/exe link for the
> connecting client."

Racy and unsafe, as previously noted.

However, I did post a patch to split the ptrace checking in proc that
should change SELinux to only checking <sourcedomain>
<targetdomain>:file read; for access to those symlinks and environ like
it used to do prior to 2.6.18.  See the separate thread.  So if you want
to get that added to the F10/rawhide kernel, you can take that up with
Eric.

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