On Tue, 2006-11-28 at 21:01 -0600, Jason L Tibbitts III wrote:
Thanks for the info!
>>>>> "SS" == Stephen Smalley <sds(a)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.
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