seccomp tangle

Hal Murray hmurray at megapathdsl.net
Sun Feb 23 10:59:09 UTC 2020


[Was Subject: Re: Is there a clean way for waf to test for the distro?]
>  Are you really, absolutely, positively sure that you can't check for the
> feature itself directly. If you start going down the distro-checking path,
> things get very messy, very fast. For example, is "Linux Mint" like Ubuntu? 

No, but I don't have any good ideas.  Would a configure option be better? (or 
less worse)

The current status is that seccomp is broken on Arch.  I was looking for a 
hack that would save me an edit every time I wanted to test on Arch.  Let's 
look at the big picture.

Here is the current status.

Something changed on Fedora a month or two ago.   There is a line of code that 
is needed on Arch but dies on Fedora.  An ifdef that used to work now fails.  
So I commented it out.  If you want to use seccomp on Arch, you have to edit 
that line.  I just discovered that Arch now needs another syscall so I'm 
getting my nose rubbed in this area again.

Looks like Fedora may have fixed something.  More later after I've had time 
for more testing.

---------

But as long as I'm typing stuff in...

Should we drop secomp?  It's a pain to maintain.

How many people use it?  Richard: do you turn it on for the Debian builds?

How does seccomp compare to a jail?  Why don't we have a good web page on how 
to setup and use a jail?  Does systemd have a jail option?  Does anybody run 
in a jail?  ...

The root of the problem is that the list of syscalls that are actually used 
depends upon which version of the kernel and which version of the libraries 
you are using, and which hardware, and ...

We dance around that by adding all the calls that are needed by any 
distro/version to the allowed list.  So on most systems, we allow some calls 
that we never use because they are used on some other system.  The catch is 
that some systems don't support some calls, so we have an ifdef to skip those 
-- they can't be used on this system if the kernel doesn't know about them so 
the skip is logically correct.

Testing the version of the seccomp header file is probably cleaner than 
testing for Arch.

-----------

Assuming we wanted to clean up the current mess...

I think we can get a list of the calls that are actually used via strace and a 
script.  The idea is to run it on a particular distro/version and make the 
list of the syscalls that this system uses.

We could read that list at either build time or run time.  A run time option 
would simplify testing.

We might have to special case a few corner cases.  I'm thinking of something 
like the script adds them in even if it doesn't see any examples.  I can't 
think of any good examples but I'd be surprised if there aren't a few calls 
that are only used in rare cases.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list