Let's enable AppArmor by default (why not?)

Re:Let's enable AppArmor by default (why not?) by language on Thursday October 12, 2017 @10:52AM (#15458383)

I was under the impression that seccomp was a bit more flexible (via ptrace() and BPF fanciness) - although I guess you'd need other co-operating processes in userspace? I've only played around with it a tiny bit.

Also, both kinds of policy are resident in files. I don't understand your point there.

[ Parent | on HN ]

Re:Let's enable AppArmor by default (why not?) by ris on Thursday October 12, 2017 @01:32PM (#15459644)

It is flexible to an extent, but you still can't e.g. deference a pointer to a struct passed as an argument. And that's where much of the interesting detail is for many calls.

[ Parent | on HN ]

Re:Let's enable AppArmor by default (why not?) by language on Thursday October 12, 2017 @04:40PM (#15461143)

Thanks for the clarification, although I recall messing with eBPF and kprobes before - pretty sure you can dereference pointers?

editx2: Oh, guess seccomp doesn't use eBPF yet? Suppose that raises a bunch of questions about permissions necessary for specifying programs that might dereference kernel pointers and such by emitting `bpf()` calls.

[ Parent | on HN ]