Script to check security?

[Bob Gustafson]

On Fri, 28 May 2004 13:11:14 -0400, Valdis.Kletnieks at vt.edu wrote:
>On Fri, 28 May 2004 11:51:38 CDT, Bob Gustafson <bobgus at rcn.com>  said:
>> >/datastore/mydata(/.*)?               system_u:object_r:mysqld_db_t
>> >/datastore(/.*)?               system_u:object_r:mysqld_db_t
>> >
>> > (Hint - what happens if there's a /datastore/otherstuff directory?)
>
>> Assuming that /datastore/mydata(/.*) is more restrictive than
>> /datastore(/.*), the testing probe could be a small program that 'looks
>> like' mysqld (assumes same roles with same selinux tags as mysqld) which
>> tries to access files in the 'crack' between /datastore/mydata and
>> /datastore. As part of the testing procedure, files could be dropped in the
>> 'crack' for this test program to access.
>
>Yes.  However, you just forgot to verify that SAS still works when accessing
>its datasets in /datastore/otherstuff because it's labeled mysql_db_t instead
>of whatever it should have been for SAS...
>
>Or maybe it wasn't SAS, but Mathematica.  Or was it that other app???

The 'test suite', just like the build tool 'configure', would be a
collection of probes and test wrappers. SAS and Mathematica would also have
their own modular piece of the test script (and have their files properly
labeled).

Perhaps these test script modules will converge to some common form which
can be customized a bit for the 'next' application. Much of the GNU build
process has evolved to mostly the same code for different applications -
just a few names are changed at a higher level.

The process of doing it, finding the problems, and then finding the
commonality in the checks, and using the commonality to simplify the system
is very important. SELinux is a whack at developing a useful language for
this commonality. Using the policy to nudge the kernel development is the
next step. (or maybe the step after next..)

>
>(Yes, it was a trick question to make a point....)

Keep 'em coming.