Hi Paul,
The system call filtering I have is:
*seccomp_rule_add(ctx, SCMP_FAIL, SCMP_SYS(clone), 1,*
* SCMP_A0(SCMP_CMP_MASKED_EQ, CLONE_NEWUSER,
CLONE_NEWUSER))*
I tested it a couple of times and noticed that the system_call filtering
only happens when I use - *SCMP_A0*.
When I use *SCMP_A1*, the use of different flags *CLONE_VFORK*,
*CLONE_NEWNET*, *CLONE_NEWUSER *the call to clone() sometimes fails and
sometimes works. This might be something to do with the container I've
implemented.
I then went to clone(2) man page and checked under NOTES, which explains
the argument ordering for the raw-clone() system call. For x86_64 it is:
*long clone(unsigned long **flags**, void ***child_stack**,*
*int ***ptid**, int ***ctid**,*
*unsigned long **newtls**);*
So it seems that the flags are indeed the first argument in the raw
system call for clone() in x86_64.
However, it is still confusing what strace shows. Is it some other
wrapper function on top of the raw call?
Thank you very much!!
Best
Shabir
On Wed, Dec 5, 2018 at 12:53 PM Paul Moore <[email protected]> wrote:
> On Tue, Dec 4, 2018 at 7:07 PM Shabir Mean <[email protected]> wrote:
> > On Tuesday, December 4, 2018 at 5:15:00 PM UTC-5, Paul Moore wrote:
> > > On Tue, Dec 4, 2018 at 4:40 PM <[email protected]> wrote:
> > > > Hi,
> > > >
> > > > I am trying to add a rule to block the clone() syscall when its
> called with the CLONE_NEWUSER flag. I want to allow the other flags to work.
> > > >
> > > > How I did this was:
> > > >
> > > > seccomp_rule_add(ctx, SCMP_FAIL, SCMP_SYS(clone), 1,
> > > > SCMP_A2(SCMP_CMP_MASKED_EQ,
> CLONE_NEWUSER, CLONE_NEWUSER))
> > > >
> > > >
> > > > Notice that the SCMP macro used is SCMP_A2 since the flags in the
> clone() system call is provided at the 3rd argument. However, this doesn't
> seem to work.
> > > >
> > > > It only works when I use SCMP_A0. Why is this happening? What could
> be the reason?
> > > > Am I missing something? I couldn't find any information on it and
> the examples on the man-page seem to be suggesting the above.
> > >
> > > What architecture are you running on? Unfortunately the clone()
> > > syscall has different argument ordering depending on the architecture,
> > > that may be what is happening here. You can use strace to verify the
> > > syscall argument order.
> > >
> > > Eventually I want libseccomp to abstract things like this away from
> > > the callers, but we are not there yet.
> >
> > Hi Paul,
> >
> > Thank you for the quick response.
> > I am running on:
> > Kernel Version 4.4.0-79-generic on a x86_64 running Ubuntu
> >
> > A strace on a simple program with clone prints the following:
> > clone(child_stack=0x7f1853b4e000, flags=CLONE_NEWUSER|SIGCHLD)
> >
> > So should it be SCMP_A1 instead of SCMP_A0?
>
> It looks like your system is passing the clone(2) flags as the second
> argument, so yes, I would suggest using SCMP_A1(...) in your
> libseccomp filter. Let us know if that works.
>
> --
> paul moore
> www.paul-moore.com
>
--
*---------------------------------------*
*Shabir Abdul Samadh**Research Assistant*
*ANRL Lab - McGill University*
--
You received this message because you are subscribed to the Google Groups
"libseccomp" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
