On Wed, 2007-10-17 at 14:46 -0500, Arthur Pemberton wrote: > On 10/17/07, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > > Arthur Pemberton wrote: > > > > >> If I asked how to determine whether or not some particular access would > > >> be permitted or denied by the traditional unix mechanism you wouldn't > > >> have any trouble describing how to verify it in terms of permissions > > >> down the file path. I'm asking the same question about SELinux. > > > > > > 1) familiarize ones self with the rules , as one has to do with > > > traditional secuirty > > > > But the traditional unix rules are extremely simple, and being able to > > understand and verify them is one of their biggest virtues. > > > > > 2) or just try it and see if it is allowed or not > > > > When something applies only to a particular process, how can you try it > > without running that process - which may have destructive side effects > > if it fails? > > > > >> How, for example, would you determine if some change will make it > > >> necessary to relabel? How, other than running something and letting it > > >> fail to get the log message, do you positively determine that some > > >> specific access will be permitted or denied? > > > > > > perms can be viewed with `ls` and there is some command that provides > > > the current settings. > > > > > > How would you do it with traditional tools? > > > > > The shortcut test is to su to the user in question and try to access the > > file/device. The only slightly more complicated way is to walk down the > > path looking at the permissions for user/group/other on the file and the > > directories above. > > Well, these "traditional" methods didn't work for your friend Karl, > since he was hacked with them. What good is a bullet-proof vest when you're going to stick the gun in your mouth anyway?
