On Thu, 27 May 2004 14:00:53 -0400, Valdis.Kletnieks wrote:
On Thu, 27 May 2004 11:59:24 CDT, Bob Gustafson <bobgus(a)rcn.com>
> Is there a script around somewhere - something like 'configure' which is
> used at the beginning of a component build - which will query various
> pieces of a system, do a 'setenforce 1' and then try various programs and
> grep the output to give some binary answer, then do 'setenforce 0' and try
> the same program, etc.
"Testing can reveal the presence of flaws, but not their absence" -- Dykstra
Writing such a test harness for a program is a daunting challenge - the
hurdle is that although you can cover 75% of the issues simply by doing a
'setenforce 1' and seeing if the program will even start up, devising harness
cases for the other 25% is very difficult - it's often stuff like "initial
file creation" or "error handling (I've had the joy of trying to debug an
that got a permission error while trying to open an error message catalog
the human-readable form of "permission error" - instant recursive error ;)
My posting about mysql the other day was related to another project of
involves a multi-gigabyte mysql database. The as-shipped mysql.fc labels
with the assumption that /var/lib/mysql/<dbname> is where the database lives.
Now, either I get to live with a 40-gigabyte /var, or I also stick a
on the /datastore/<dbname> tree where the database actually resides.
Now for those of you listening at home - devise a test that will catch the
difference between these two lines:
(Hint - what happens if there's a /datastore/otherstuff directory?)
(I do need to read more of the FAQs and docs, but here is a stab..)
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.
(File access could be generalized to cover shared memory access, sockets, etc.)
Another wrinkle would be to add an error return code (or codes) to all of
the OS file access routines which would tell a calling program that it was
trying to open a file without sufficient SELinux permission (maybe this has
been done already). This feature would help to make probes a bit more
If probe programs were written in great numbers, the /var/log/messages file
would be a large problem. Something would need to be done that would turn
off logging during probe testing, or some such. This would have to be done
carefully as it is would be a big door for hackers.
With a good testing scheme, patterns would begin to emerge which could be
used to simplify and regularize OS access needs. 'Simple' means that proof
testing would have a better chance.
> This script would help to give struggling sysadmins some degree of
> confidence that what is being done to their 'policy.local' or whatever, is
It's feasible to set up a script that verifies that a given program is given
"enough" access - see 'audit2allow'. It's another challenge
that it is in fact the minimal set of required access - mostly because it has
no way to identify what "proper" means.
(Hmm... I'm trying to figure out if the generic case of computing "minimal
is the equivalent of the Halting Problem. It's actually probably fairly
with static code analysis, except that programmers have this very annoying
tendency to do stuff like call sprintf(foo,"%s", user_file); and then
open(foo)... And sometimes they actually *want* a "../.." pattern in foo. ;)