Quoting Paul Moore ([email protected]):
> On Wednesday, June 18, 2014 08:31:42 PM Serge Hallyn wrote:
> > Hi,
> >
> > As i was testing the blacklisting of finit_modules, I ran across what
> > appears to be a systematic (cut-paste?) error in
> > src/arch-x86_64-syscalls.c. It has for instance
> >
> > { "fchown32", __PNR_fchown32 },
> > ...
> > { "finit_module", __PNR_finit_module },
>
> Hmm, looking at the current kernel sources those two syscalls are indeed
> defined. In the case of finit_module it looks like it was added in 3.8 (the
> x86_64 syscall table was based on 3.4.7) so it was missing in the initial
> table and the pseudo-syscall entry was added along with the initial ARM
> support.
>
> This is clearly a bug.
>
> > However, seccomp.h.in has stanzas like
> >
> > #define __PNR_fchown32 -10008
> > #ifndef __NR_fchown32
> > #define __NR_fchown32 __PNR_fchown32
> > #endif /* __NR_fchown32 */
> >
> > #define __PNR_finit_module -10085
> > #ifndef __NR_finit_module
> > #define __NR_finit_module __PNR_finit_module
> > #endif /* __NR_finit_module */
> >
> > As a result, on my 3.15 host I'm getting a negative return value when
> > resolving finit_module and fchown32, and am not able to blacklist them.
>
> I'm guessing you're using the seccomp_add_rule_exact() API?
The code is:
nr = seccomp_syscall_resolve_name_arch(arch, line);
if (nr < 0) {
WARN("Seccomp: failed to resolve syscall: %s (returned %d)",
line, nr);
WARN("This syscall will NOT be blacklisted");
continue;
}
ret = seccomp_rule_add(ctx ? ctx : conf->seccomp_ctx,
action, nr, 0);
if (ret < 0) {
ERROR("failed (%d) loading rule for %s", ret, line);
goto bad_rule;
}
Now if I change that so that it tries to add the negative rule, the
seccomp_rule_add() does not return failure, but experiment shows that
the syscall is not in fact rejected (as it is when I use 'delete_module',
which has a positive #, instead of 'finit_module').
> > It seems to me therefore that src/arch-x86_64-syscalls.c should have
> >
> > { "fchown32", __NR_fchown32 },
> > ...
> > { "finit_module", __NR_finit_module },
>
> Yep.
>
> Patches are always welcome ;)
Ok, I wanted to see if I was misunderstanding something first, but I'll
probably send a patch tonight.
> > and the same for all other __PNR entries. In fact looking at grep output
> > it seems
> >
> > sed -i 's/__PNR_/__NR_/ src/arch-*-syscalls.c
> >
> > should be safe...
>
> Nope. The __PNR_* defines are for syscalls that do not exist for a given
> arch/ABI. While in the two examples above we should be using the __NR_*
> equivalents, there are legitimate uses for the __PNR_* defines.
Absolutely, and I'm not saying to get rid of them everywhere, but I'm
saying that if in all cases __NR_foo falls back to __PNR_foo when
#ifndef __NR_FOO, then arch-*-syscalls.c can always use __NR_FOO, and
then whether defined or not it'll do the right thing.
thanks,
-serge
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
libseccomp-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
