On 12/20/2016 8:50 AM, Stephen Smalley wrote: > On Tue, 2016-12-20 at 17:39 +0100, José Bollo wrote: >> Le mardi 20 décembre 2016 à 11:14 -0500, Stephen Smalley a écrit : >>> >>> Looking at your PTAGS implementation, I feel it is only fair to >>> warn >>> you that your usage of /proc/pid/attr is insecure, regardless of >>> whether you use task security blobs or cred security blobs. >> Fair?! >> >>> Getting the attributes of another process via /proc/pid files is >>> inherently racy, as the process may exit and another process with >>> different attributes may be created with the same pid (and no, this >>> is not theoretical; it has been demonstrated). >> I know. And I'm surprized that you dont do anything to change that. > There is a reason why SO_PEERSEC and SCM_SECURITY exist. Again, learn > from the upstream security modules rather than re-inventing them, > badly. SO_PEERSEC and SCM_SECURITY are spiffy for processes that are sending each other messages, but they identify the attributes associated with the message, not the process. Neither SELinux nor Smack get the information to send off of the process, it comes from the socket structure. > >>> Similarly, setting the >>> attributes of another process via /proc/pid files is likewise >>> inherently racy; you may end up setting the attributes on the wrong >>> process entirely. >> I also know that. >> >>> Setting another process' attributes in this manner >>> is also prone to other kinds of races, since there is no >>> coordination >>> between the process execution state and when the new tag is >>> applied. >> Yes it is expected. >> >>> Again, I encourage you to reconsider your approach if you want to >>> have a secure solution. >> Well I know that managing processes is not secure because there is no >> kind of unique id. But please instead of thinking that it is to >> risky, >> please hear that some risks are manageable or acceptable. > Even when there are known, better ways of doing things? -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
