On Sat, 29 May 2004 11:14, Bob Gustafson <bobgus@xxxxxxx> wrote: > 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). This MAY detect that the program operates correctly (which is more difficult than you may imagine in the case of programs that launch other programs in different domains - think of checking password access by pam_unix.so). However it does not help for the more difficult problems, such as determining that the program is not given excessive permissions. Many programs routinely try to access things that they don't need, one of the most difficult parts of writing SE Linux policy is deciding when to use a dontaudit rule for such things. > 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. I've been trying to encourage post-grad students to do a Ph.D thesis on a related topic. So far no-one has been interested. It's generally regarded that this problem is not solvable in the general case, but I think that a good Ph.D project could get a usable partial solution. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
