Stephen Smalley wrote: > mcstransd I tried to use this daemon at first but it appeared to require one translation line for each possible combination of the categories and even ranges of them. For example, on a particular centos 5 machine I have to specify s0-s0:c0=coreprocess s0-s0:c1=webprocess s0:c0=core s0:c1=web Actually the same behavior is illustrated by the default s0-s0:c0.c1023=SystemLow-SystemHigh s0:c0.c1023=SystemHigh confusingly enough, s0 does not equal SystemLow but an empty string. I recall reading a presentation (IIRC from a symposium proceeding) that would suggest an improvement was planned here, but how far has that effort progressed? OTOH I somehow feel safer to have the words 'core' and 'web' stored directly in the inode of the disk rather than rely on a run time mapping from some generic number. (That's why I don't like unix UID/GIDs too much either.) Finally, it would appear that even the most smart mcstransd can't do too much about the 'rangeizing' feature. The kernel itself presents c0,c1,c2 as c0.c2, so mcstrans can only *guess* that there is a c1 in between. Or is there a way to query the kernel about the exact list of categories? > It also serves a practical end - keeping context string sizes sane for > kernel interfaces (/selinux/* and /proc/self/attr/*). Does a category length such as 16 characters classify as 'sane' too, or is there a noticeable overhead? > I think we're open to improvements in this area, but naturally we will > need to retain compatibility for the current users of the dot > notation. We have talked in the past about improving direct kernel > support for complex label encodings, but unfortunately no one has > really moved forward in that space. Do you have some pointers to these talks? Regards, Michal Svoboda
Attachment:
pgps0eyDkgRPM.pgp
Description: PGP signature
