Re: Re: Firejail local root exploit

[Martin Carpenter <mcarpenter () free fr>]

On Fri, 2017-01-06 at 18:08 +0100, sivmu wrote:
> Non-priv users can run seccomp filter on anything anyway.

prctl(PR_CAPBSET_DROP, ...) (see caps.c) requires CAP_SETPCAP. 


> Seccomp does not rewuire any privileges and as far as I know it onl
> restricts permissions (to use syscalls) and never expands them.

To be clear I was pondering the SECCOMP_RET_ERRNO case (not the more
typical case where uncatchable SIGKILL zaps the caller) and I don't
think this is feasible with current firejail. "waiting to happen", as I
said in my throwaway comment.

But if a non-privileged user can make the OS lie to a privileged (eg
setuid) program then there is clearly potential for shenanigans. There
is some similarity with FUSE -- make the OS lie about the state of the
file system -- but the barrier to entry is significantly higher for FUSE
(fuse group, allow_root, etc).

Maybe you could even persuade a seccomp-SIGKILLed process to leave the
system in some weird exploitable state. Eg rather than racing a chmod,
just have seccomp kill the process at that point. (That's a bit
hand-wavy -- the race is the problem in that example -- but hopefully
you can see what I'm trying to say).

The fact that I can't easily reason about this, that I can't say "this
strategy is safe", makes me uneasy.


> Also the question is how many of these issues are specific to firejail
> and how many of them also applied to (user)namespaces in general or
> wrapper tool lke bubblewrap that utilise namespaces as firejail does.
>
> Meaning some of these issues could applie to a lot more programms.

Potentially, yes. Though bubblewrap is both more conservative and has a
cleaner approach to privilege management. Nice cat, too.


Martin.