On Sat, Apr 22, 2017 at 2:12 AM, Djalal Harouni <tixxdz@xxxxxxxxx> wrote: > On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > [...] >>>> I personally like my implicit_rights idea, and it might be interesting >>>> to prototype it. >>> >>> I don't like blocking a needed feature behind a large super-feature >>> that doesn't exist yet. We'd be able to refactor this code into using >>> such a thing in the future, so I'd prefer to move ahead with this >>> since it would stop actual exploits. >> >> I don't think the super-feature is so hard, and I think we should not >> add the per-task thing the way it's done in this patch. Let's not add >> per-task things where the best argument for their security is "not >> sure how it would be exploited". > > Actually the XFRM framework CVE-2017-7184 [1] is one real example, of > course there are others. The exploit was used on a generic distro > during a security contest that distro is Ubuntu. That distro will > never provide a module autoloading restriction by default to not harm > it's users. Consumers or containers/sandboxes then can run their > confined apps using such facilities. > > These bugs will stay in embedded devices that use these generic > distros for ever. The DCCP CVE-2017-6074 exploit: http://seclists.org/oss-sec/2017/q1/503 Well, pretty sure there is more... the bugs are real, as their exploits. Anyway I think these features can coexist as they are optional, and most process trees protections can get along by design. -- tixxdz -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html