Policy for denyhosts
Jason L Tibbitts III
tibbs at math.uh.edu
Wed Nov 29 03:01:58 UTC 2006
Thanks for the info!
>>>>> "SS" == Stephen Smalley <sds at tycho.nsa.gov> 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.
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.
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?
I'll have to dig into the policy bits you sent; most of it is
self-explanatory but I'm sure there are many subtleties I'm missing.
- J<
More information about the fedora-selinux-list
mailing list