Re: Policy for denyhosts

[Stephen Smalley <sds tycho nsa gov>]

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