-----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@xxxxxxxxxxxxx |> |> 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
