On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris <eparis@xxxxxxxxxx> writes: > So what happens when I create a file /home/john/shadow, does selinux > (or LSM in general) then run extra checks because the filename is > 'shadow' in your model? It's entirely a question of labeling and one that was discussed on the LSM list in some detail: http://marc.info/?t=129141308200002&r=1&w=2 The basic synopsis is that when a new inode is created SELinux must apply some label. It makes the decision for what label to apply based on 3 pieces of information. The label of the parent inode. The label of the process creating the new inode. The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc This patch adds a 4th piece of information, the name of the object being created. An obvious situation where this will be useful is devtmpfs (although you'll find other examples in the above thread). devtmpfs when it creates char/block devices is unable to distinguish between kmem and console and so they are created with a generic label. hotplug/udev is then called which does some pathname like matching and relabels them to something more specific. We've found that many people are able to race against this particular updating and get spurious denials in /dev. With this patch devtmpfs will be able to get the labels correct to begin with. I'm certainly willing to discuss the security implications of this patch, but that would probably be best done with a significantly shortened cc-list. You'll see in the above mentioned thread that a number of 'security' people (even those who are staunchly anti-SELinux) recognize there is value in this and that it is certainly much better than we have today. > I *think* the overhead shouldn't be there if SELINUX is disabled, but > have you confirmed this? How you run performance tests before/after > this change when doing lots of creations of inodes to see what sort of > performance changes might be there? I've actually recently done some perf testing on creating large numbers of inodes using bonnie++, since SELinux was a noticeable overhead in that operation. Doing that same test with SELinux disabled (or enabled) I do not see a noticeable difference when this patch is applied or not. It's just an extra argument to a function that goes unused. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
