Selinux and denyhosts

[Jason L Tibbitts III]

I maintain the denyhosts package in Fedora Extras.  Recently a user
reported that denyhosts resets the security context on /etc/hosts.deny
which breaks other services.  (The ticket is
https://bugzilla.redhat.com/212771 .)

It isn't completely clear what is happening from the report.
Denyhosts performs two operations on hosts.deny:

1) When adding new hosts, it appends (usually) two lines to the file.
2) When purging old hosts, it creates a new temporary file (currently
   named hosts.deny.purge.tmp, although there's certainly no permanent
   guarantee of this), copies over the lines not being purged, and
   then renames the new file into place.

My understanding is that the first operation won't change the security
context of the file, but the second is quite likely to.

Unfortunately the reporter hasn't provided any information about
whether my last suggestion of running

semanage fcontext -a -t etc_t /etc/hosts.deny.purge.tmp

or using a pattern helped the situation.  My understanding is that
this should fix the issue, but I am far from a selinux expert.  Might
anyone have additional advice?  Is there any way to future-proof this
in case upstream decides to use a different temporary filename?  Would
it be reasonable to create a full policy for denyhosts?

 - J<

[Paul Howarth]

Jason L Tibbitts III wrote:
>  I maintain the denyhosts package in Fedora Extras.  Recently a user
>  reported that denyhosts resets the security context on /etc/hosts.deny
>  which breaks other services.  (The ticket is
>  https://bugzilla.redhat.com/212771 .)
>  
>  It isn't completely clear what is happening from the report.
>  Denyhosts performs two operations on hosts.deny:
>  
>  1) When adding new hosts, it appends (usually) two lines to the file.
>  2) When purging old hosts, it creates a new temporary file (currently
>     named hosts.deny.purge.tmp, although there's certainly no permanent
>     guarantee of this), copies over the lines not being purged, and
>     then renames the new file into place.
>  
>  My understanding is that the first operation won't change the security
>  context of the file, but the second is quite likely to.
>  
>  Unfortunately the reporter hasn't provided any information about
>  whether my last suggestion of running
>  
>  semanage fcontext -a -t etc_t /etc/hosts.deny.purge.tmp
>  
>  or using a pattern helped the situation.  My understanding is that
>  this should fix the issue, but I am far from a selinux expert.  Might
>  anyone have additional advice?  Is there any way to future-proof this
>  in case upstream decides to use a different temporary filename?  Would
>  it be reasonable to create a full policy for denyhosts? 
Using semanage like this is unlikely to improve the situation, as the 
pathname-based default file contexts that it manages are used only in a 
few special circumstances, such as installing packages or using 
"restorecon".

I think the suggestion in comment #2 of running restorecon on the new 
file is the safest one, as it will work if the default context of the 
hosts.deny file changes. Of course, this will leave a small window of 
time where the file has the wrong context between creation of the new 
file and the running of restorecon, so you might also consider doing the 
equivalent of "chcon -t etc_t $TMPFILE" before moving it into place.

It'd be nice if there was a way of setting the context of a file to be 
the same as the context of another file (somewhat like the --reference 
option of touch), which would be useful in cases like this.

Paul.

[Karl MacMillan]

On Thu, 2006-11-02 at 16:45 +0000, Paul Howarth wrote:
>  Jason L Tibbitts III wrote:
>  > I maintain the denyhosts package in Fedora Extras.  Recently a user
>  > reported that denyhosts resets the security context on /etc/hosts.deny
>  > which breaks other services.  (The ticket is
>  > https://bugzilla.redhat.com/212771 .)
>  > 
>  > It isn't completely clear what is happening from the report.
>  > Denyhosts performs two operations on hosts.deny:
>  > 
>  > 1) When adding new hosts, it appends (usually) two lines to the file.
>  > 2) When purging old hosts, it creates a new temporary file (currently
>  >    named hosts.deny.purge.tmp, although there's certainly no permanent
>  >    guarantee of this), copies over the lines not being purged, and
>  >    then renames the new file into place.
>  > 
>  > My understanding is that the first operation won't change the security
>  > context of the file, but the second is quite likely to.
>  > 
>  > Unfortunately the reporter hasn't provided any information about
>  > whether my last suggestion of running
>  > 
>  > semanage fcontext -a -t etc_t /etc/hosts.deny.purge.tmp
>  > 
>  > or using a pattern helped the situation.  My understanding is that
>  > this should fix the issue, but I am far from a selinux expert.  Might
>  > anyone have additional advice?  Is there any way to future-proof this
>  > in case upstream decides to use a different temporary filename?  Would
>  > it be reasonable to create a full policy for denyhosts?
>  
>  Using semanage like this is unlikely to improve the situation, as the 
>  pathname-based default file contexts that it manages are used only in a 
>  few special circumstances, such as installing packages or using 
>  "restorecon".
>  
>  I think the suggestion in comment #2 of running restorecon on the new 
>  file is the safest one, as it will work if the default context of the 
>  hosts.deny file changes. Of course, this will leave a small window of 
>  time where the file has the wrong context between creation of the new 
>  file and the running of restorecon, so you might also consider doing the 
>  equivalent of "chcon -t etc_t $TMPFILE" before moving it into place.
>   
The context should be set on the new file when it is created, otherwise
the data in the file would be stored with the wrong context for the
duration of the processing - just like the race you are describing when
it is moved into place.

>  It'd be nice if there was a way of setting the context of a file
> to be 
>  the same as the context of another file (somewhat like the --reference 
>  option of touch), which would be useful in cases like this.
>   
There is - see getfilecon and setfscreatecon in the selinux python
module. It should also be possible to use type_transitions in a
denyhosts policy to handle this. A quick glance at denyhosts suggests
that a policy might be a good idea anyway.

Karl

>  Paul.
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Stephen Smalley]

On Thu, 2006-11-02 at 16:45 +0000, Paul Howarth wrote:
>  Jason L Tibbitts III wrote:
>  > I maintain the denyhosts package in Fedora Extras.  Recently a user
>  > reported that denyhosts resets the security context on /etc/hosts.deny
>  > which breaks other services.  (The ticket is
>  > https://bugzilla.redhat.com/212771 .)
>  > 
>  > It isn't completely clear what is happening from the report.
>  > Denyhosts performs two operations on hosts.deny:
>  > 
>  > 1) When adding new hosts, it appends (usually) two lines to the file.
>  > 2) When purging old hosts, it creates a new temporary file (currently
>  >    named hosts.deny.purge.tmp, although there's certainly no permanent
>  >    guarantee of this), copies over the lines not being purged, and
>  >    then renames the new file into place.
>  > 
>  > My understanding is that the first operation won't change the security
>  > context of the file, but the second is quite likely to.
>  > 
>  > Unfortunately the reporter hasn't provided any information about
>  > whether my last suggestion of running
>  > 
>  > semanage fcontext -a -t etc_t /etc/hosts.deny.purge.tmp
>  > 
>  > or using a pattern helped the situation.  My understanding is that
>  > this should fix the issue, but I am far from a selinux expert.  Might
>  > anyone have additional advice?  Is there any way to future-proof this
>  > in case upstream decides to use a different temporary filename?  Would
>  > it be reasonable to create a full policy for denyhosts?
>  
>  Using semanage like this is unlikely to improve the situation, as the 
>  pathname-based default file contexts that it manages are used only in a 
>  few special circumstances, such as installing packages or using 
>  "restorecon".
>  
>  I think the suggestion in comment #2 of running restorecon on the new 
>  file is the safest one, as it will work if the default context of the 
>  hosts.deny file changes. Of course, this will leave a small window of 
>  time where the file has the wrong context between creation of the new 
>  file and the running of restorecon, so you might also consider doing the 
>  equivalent of "chcon -t etc_t $TMPFILE" before moving it into place.
>  
>  It'd be nice if there was a way of setting the context of a file to be 
>  the same as the context of another file (somewhat like the --reference 
>  option of touch), which would be useful in cases like tqhis. 
chcon has an option for that, e.g.
	chcon --reference /etc/hosts.deny $TMPFILE

But Karl is correct - you want to create the file in the right context
in the first place, and this can be done via policy (type transition
rules) or by code (having the application that creates the temporary
file use getfilecon to get the original context and setfscreatecon to
specify that context for use in subsequent file creations).

-- 
Stephen Smalley
National Security Agency