Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 07 Jan 2017 14:21:15 +0100
From: Martin Carpenter <>
Subject: Re: Re: Firejail local root exploit

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.


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ