On Wed, Oct 17, 2018 at 06:15:47PM +0000, Michael Tirado wrote: > Tycho, Sorry for the duplicate, I forgot to CC the list :( > > On Wed, Oct 17, 2018 at 3:00 PM Tycho Andersen <ty...@tycho.ws> wrote: > > > > > > That's one of the use cases, but there are a large number of others. I > > discuss a few in patch 1: > > https://www.spinics.net/lists/linux-containers/msg33956.html > > > > Thanks this is making more sense to me now. > > I haven't been keeping up with the list and just did a bunch > of reading. It seems that stackable LSM's are making some real > progress now, and I wonder if those patches are merged would > using a stacked security module approach be worth exploring if > it provides the same or greater flexibility, and assuming all > syscalls of interest can be hooked somehow?
Sorry, I somehow just noticed that this was a duplicate and the one I replied to was the off-list one. Anyway, no, I don't think that'll work. The LSM code right now can't do anything besides refuse an access, and that's a very specific design constraint of it. In particular, it can't mutate any task state or anything. What we want in this series is basically the equivalent of SECCOMP_RET_TRACE, without having to involve ptrace (for a variety of reasons, mostly that applications want to use ptrace for their own things). So seccomp seems like the most natural fit. Tycho
