On Friday, June 20, 2014 06:51:49 PM Serge Hallyn wrote: > Quoting Paul Moore ([email protected]): > > On Thursday, June 19, 2014 02:18:16 AM Serge Hallyn wrote: > > > include/seccomp.h carefully sets __NR_foo to a negative number if > > > the syscall name is not known. However when actually filling in the > > > per-arch syscall tables, we were unconditionally inserting the > > > negative numbers. This patch uses the __NR_foo (which is the real > > > syscall if known, or the negative number if unknown) in place of > > > the __PNR_foo (the negative number). > > > > > > Without this patch, using > > > seccomp_syscall_resolve_name_arch(finit_module), > > > for instance, always returned a negative number, and using > > > seccomp_add_rule on the result had no effect. With this patch, > > > finit_module becomes properly confined. > > > > > > Signed-off-by: Serge Hallyn <[email protected]> > > > > Sorta. > > > > I guess I'm not being very clear, if an ABI doesn't define a given syscall > > then we should leave the syscall number as the __PNR_* value. > > With my patch, if the syscall is not known at build time then it will be > returned as the __PNR_* value.
What about the x86 syscall table when compiled on a x86_64 system? What about a MIPS syscall table when compiled on an ARM system (okay, this is contrived but it makes a point)? The current policy is that libseccomp should be able to generate filters for any ABI regardless of the host system. Unless I'm mistaken this patch breaks that policy. > If we don't do this, then the seccomp_syscall_resolve_name() family of > calls becomes worthless to me, and I'm better off checking unistd.h myself. > (Because here now i'm trying to filter module insertion, but because > finit_module is unknown there is libseccomp-linked program that will be > able to filter it) No, we just need to update/fix the syscall tables. We've established that the syscall tables are outdated, the correct solution is to simply update them, not throw out mechanisms we've built to support multiple architectures. If you aren't able to provide a patch, I'll take care of it, but I'm still in the middle of the MIPS64 code and making sure the AArch64 guys have what they need. You are also welcome to go off and roll your own hack that sifts through unistd.h. Oh the wacky benefits of Open Source :) > > Spot checking > > your patch below I see a few invalid syscalls given __NR_* values. > > What do you mean by invalid? I saw a few ARM specific syscalls in the MIPS syscall table that had __NR_* values. That is invalid by almost any definition as far as I'm concerned. > The only reason why any should not be > changed (and I did NOT check whether there are such, so there might > be) is if there are some which do not have a > > #ifndef __NR_foo > #define __NR_foo __PNR_foo > #endif > > stanza in libseccomp.h Like I said earlier, think beyond the native architecture and I think this will make more sense. > > I agree that the syscall tables could use an update, you've already > > identified a few x86_64 syscalls that have been added since the table was > > created, but simply changing __PNR_* to __NR_* is not the answer. > > I'm not changing __PNR_*. I'm letting the userspace on the compile host > decide what number to fill into the syscall tables. ... and that is exactly the problem. -- paul moore security and virtualization @ redhat ------------------------------------------------------------------------------ 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
