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