On Fri, 28 May 2004 13:11:14 -0400, Valdis.Kletnieks@xxxxxx wrote: >On Fri, 28 May 2004 11:51:38 CDT, Bob Gustafson <bobgus@xxxxxxx> 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.
