[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1483795275.8979.125.camel@juliet.mcarpenter.org>
Date: Sat, 07 Jan 2017 14:21:15 +0100
From: Martin Carpenter <mcarpenter@...e.fr>
To: oss-security@...ts.openwall.com
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.
Martin.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
