On Tue, 2006-11-28 at 21:01 -0600, Jason L Tibbitts III wrote: > Thanks for the info! > > >>>>> "SS" == Stephen Smalley <sds@xxxxxxxxxxxxx> writes: > > SS> The delicate issue there is that other programs read > SS> /etc/hosts.deny, so if we move it into its own type (so that we > SS> only have to allow denyhosts to write to it and not other files in > SS> /etc), then we have to adjust any other domains that need to read > SS> the new type. > > Ah, of course, you can't allow something to read a file by name, just > by type. Mighty inconvenient, that. Inconvenient, but correct. > SS> User-supplied or admin-supplied? The scripts should run with the > SS> full privileges of denyhosts or with a reduced subset? > > Admin-supplied, I suppose. This is essentially an admin-only > application; you have to explicitly modify the root-owned config file > in order to enable a particular script. Ok, that simplifies matters. > I can't speak to what the scripts should be able to do. Folks could > be doing anything at all with them (as they're called via exec), but I > suspect they're not being used at all in the vast majority of cases. > Is it possible for the end-user (end-admin?) to do something quick to > force an executable to transition into the unconfined domain? Yes, if you include the following in your denyhosts policy: unconfined_domtrans(denyhosts_t) Then the admin would just need to assign unconfined_exec_t to the executable. But you would likely want that under a boolean too, so that an admin could choose to never allow denyhosts to escalate to unconfined. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
