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. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com )
