[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH 0/6] utrace: security problems

As to the unsafe_exec stuff, I'd long figured we would have something just
about like that.  (You might recall that an earlier utrace API had an
unsafe_exec engine callback, which had its own unresolved complications.)

For exec transitions (set-id, file caps, selinux), I'd originally figured
an engine's report_exec could check for changes and decide to detach itself
if appropriate.  We will figure out when we come to it whether that can
really cover all the exec angles or not.  setprocattr is the one other
troublesome wrinkle, which I haven't thought all that much about.

I don't think we need to, nor should, try to tie down the security-related
stuff at the outset.  We can work on prototype engines with the proviso
that they are for root only or for experimentation when one doesn't care
about security issues yet.  When we have at least a couple of different
engines with different access models, we will be better placed to figure
out how to tie in the security issues.

In the long run, the security_ptrace() granularity of hook is probably too
blunt an instrument.  We'll want to contemplate the different kinds of
engines with their different kinds of security-relevant interactions
and decide on security checking models that give the appropriate flexibility.
But it's premature to get into that before we have a bit of an ecosystem of
different sorts of modules to consider concretely.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]