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