[LTP] [PATCH 0/1] uname26 exploit regression test

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> > Sounds reasonable. I guess that for some exploits there is no single
> > syscall to blame so putting these into syscalls/ does not make much
> > sense.
> > 
> > Maybe we can just put all these tests into an security/exploits or
> > security/CVE directory or something.
> 
> Perhaps use security/CVE directory then list the exploits by CVE number is
> best. Then if someone needs to find an exploit for a particular syscall they
> will need to grep its name or they could look it up in a CVE database.

Agreed.

> Maybe you could add a field in the test struct for keywords and then at some
> later date we could add an option to the test runner to search for tests with
> some particular keywords or other meta data? (I am thinking about the -q
> option you added for runltp-ng (good work btw :-))).

I have something like that in mind, adding metadata to reference kernel
commits for regression tests, tagging System V IPC tests with 'sysv_ipc'
tag, etc. Could be done as simply as adding an array of strings (tags)
to the test structure, then we just can just print them with "tag:"
prefix for the -q option, however tagging ~1000 testcases will be quite
time consuming...

> > > 2) What is the appropriate runtest file for security tests? I think they
> > >    should be separated from functional tests.  
> > 
> > If there is none we should start one. Something as runtest/security. I'm
> > also wondering if we should add these into the runtest/syscalls as well,
> > at least these that are directly related to a syscall of some kind.
> 
> This does mean we will end up unintentionally running some tests twice,
> although maybe runltp stops that. In fact if all the tests are named cve-*
> then it is easy to stop that.

We have overlap in the runtest files at the moment, there are a few that
are a subset of the syscalls runtest file. Tagging all the tests would
fix that problem, since then we could filter tests by tags, but even if
we decide to go this way, that will took us at least year to implement.

> In any case some exploits are likely to run a long time or crash the system if
> successful so I would either want to keep them seperate or have some way of
> labeling them as dangerous or long running. For example I started running the
> OOM killer tests separately in OpenQA from the other memory tests because they
> are very good at causing freezes and stop the other tests from running.

There are at least three syscall tests that can bring the machine down
as well, mostly regresion tests for races in fs...

-- 
Cyril Hrubis
chrubis@suse.cz