Hi list,
As many of you know I am working on a Managing Confined Services guide for Fedora.
Having set up a simple squid environment on Fedora 11, with minimal and default settings in squid.conf (http_port 3128 as allowed by semanage, and a default cache_dir), I was able to create the cache directory structure, but I got a denial when actually starting squid for the first time (I assume this happens as it attempts to create its pid in /var/run):
On Mon, 15 Jun 2009 13:47:08 +1000 Scott Radvan sradvan@redhat.com wrote:
Hi list,
As many of you know I am working on a Managing Confined Services guide for Fedora.
Having set up a simple squid environment on Fedora 11, with minimal and default settings in squid.conf (http_port 3128 as allowed by semanage, and a default cache_dir), I was able to create the cache directory structure, but I got a denial when actually starting squid for the first time (I assume this happens as it attempts to create its pid in /var/run):
What's happening here is a denial for *reading* /var/run/squid.pid, which is of type var_run_t. Now in Fedora 11 this file should be labelled squid_var_run_t, and that's what it is labelled on two Fedora 11 boxes freshly installed here. It seems there's a labelling problem on your system. Can you post the output of "ls -lZa /var/run"? Is your system a fresh install or an upgrade?
Paul.
On Mon, 15 Jun 2009 07:19:39 +0100 Paul Howarth paul@city-fan.org wrote:
On Mon, 15 Jun 2009 13:47:08 +1000 Scott Radvan sradvan@redhat.com wrote:
I got a denial when actually starting squid for the first time (I assume this happens as it attempts to create its pid in /var/run):
What's happening here is a denial for *reading* /var/run/squid.pid, which is of type var_run_t. Now in Fedora 11 this file should be labelled squid_var_run_t, and that's what it is labelled on two Fedora 11 boxes freshly installed here. It seems there's a labelling problem on your system. Can you post the output of "ls -lZa /var/run"? Is your system a fresh install or an upgrade?
Paul.
I'm pretty sure I've figured out what I was doing wrong after another re-install.
I was previously starting squid directly from /usr/sbin/squid instead of using 'service squid start'. Starting it directly from /usr/sbin/squid apparently(?) doesn't initialise squid.pid as squid_var_run_t, rather it just starts as var_run_t, which is why I got a denial.
Starting squid via 'service squid start' as I should have been doing from the start is working fine now. Thanks for your help Paul.
On 06/15/2009 06:31 PM, Scott Radvan wrote:
On Mon, 15 Jun 2009 07:19:39 +0100 Paul Howarthpaul@city-fan.org wrote:
On Mon, 15 Jun 2009 13:47:08 +1000 Scott Radvansradvan@redhat.com wrote:
I got a denial when actually starting squid for the first time (I assume this happens as it attempts to create its pid in /var/run):
What's happening here is a denial for *reading* /var/run/squid.pid, which is of type var_run_t. Now in Fedora 11 this file should be labelled squid_var_run_t, and that's what it is labelled on two Fedora 11 boxes freshly installed here. It seems there's a labelling problem on your system. Can you post the output of "ls -lZa /var/run"? Is your system a fresh install or an upgrade?
Paul.
I'm pretty sure I've figured out what I was doing wrong after another re-install.
I was previously starting squid directly from /usr/sbin/squid instead of using 'service squid start'. Starting it directly from /usr/sbin/squid apparently(?) doesn't initialise squid.pid as squid_var_run_t, rather it just starts as var_run_t, which is why I got a denial.
Starting squid via 'service squid start' as I should have been doing from the start is working fine now. Thanks for your help Paul.
Unconfined processes tend to stay unconfined. That is what uses expect, telling them that they are executing an uconfined process that suddenly becomes confined, seems wrong to them. That being said, you can end up with mislabeled files because of this.
So
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.
On 06/16/2009 08:32 AM, Daniel J Walsh wrote:
Unconfined processes tend to stay unconfined. That is what uses expect, telling them that they are executing an uconfined process that suddenly becomes confined, seems wrong to them. That being said, you can end up with mislabeled files because of this.
So
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.
I also just wrote a blog on this.
On Tue, 2009-06-16 at 08:49 -0400, Daniel J Walsh wrote:
On 06/16/2009 08:32 AM, Daniel J Walsh wrote:
Unconfined processes tend to stay unconfined. That is what uses expect, telling them that they are executing an uconfined process that suddenly becomes confined, seems wrong to them. That being said, you can end up with mislabeled files because of this.
So
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.
I also just wrote a blog on this.
Hmm...when did this change? It used to be the case that a domain transition was also defined directly from unconfined_t to the daemon domain when running the daemon binary, precisely because users and scriptlets sometimes do that.
On 06/16/2009 08:57 AM, Stephen Smalley wrote:
On Tue, 2009-06-16 at 08:49 -0400, Daniel J Walsh wrote:
On 06/16/2009 08:32 AM, Daniel J Walsh wrote:
Unconfined processes tend to stay unconfined. That is what uses expect, telling them that they are executing an uconfined process that suddenly becomes confined, seems wrong to them. That being said, you can end up with mislabeled files because of this.
So
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.
I also just wrote a blog on this.
Hmm...when did this change? It used to be the case that a domain transition was also defined directly from unconfined_t to the daemon domain when running the daemon binary, precisely because users and scriptlets sometimes do that.
About FC5 time frame. The most common error caused by this was
AVC's about getattr in homedir, redirection of stdout blowing up because squid_t can not write to user_tmp_t. Etc.
On Tue, 2009-06-16 at 09:18 -0400, Daniel J Walsh wrote:
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.
The AVC denial was about squid_t trying to access var_run_t.
If unconfined_t executed squid_exec_t then the domain would not be squid_t.
If squid would run as squid_t then the pid would not be var_run_t.
The AVC denial does not seem to make sense. Maybe only if two squid processes were running, one unconfined and one confined, that were conflicting.
On 16/06/09 14:53, Dominick Grift wrote:
On Tue, 2009-06-16 at 09:18 -0400, Daniel J Walsh wrote:
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.
The AVC denial was about squid_t trying to access var_run_t.
If unconfined_t executed squid_exec_t then the domain would not be squid_t.
If squid would run as squid_t then the pid would not be var_run_t.
The AVC denial does not seem to make sense. Maybe only if two squid processes were running, one unconfined and one confined, that were conflicting.
Perhaps squid was first run unconfined, creating /var/run/squid.pid that was var_run_t, then run again using the initscript, causing the denial when trying to access the pidfile?
Paul.
On Tue, 2009-06-16 at 15:10 +0100, Paul Howarth wrote:
On 16/06/09 14:53, Dominick Grift wrote:
On Tue, 2009-06-16 at 09:18 -0400, Daniel J Walsh wrote:
unconfined_t -> squid_exec_t -> unconfined_t
But unconfined processes starting init scripts have a transition
unconfined_t -> initrc_exec_t -> initrc_t -> squid_exec_t -> squid_t
So any time you are using a confined process you should use the init script to start them, otherwise you could get mislabeled files.
The AVC denial was about squid_t trying to access var_run_t.
If unconfined_t executed squid_exec_t then the domain would not be squid_t.
If squid would run as squid_t then the pid would not be var_run_t.
The AVC denial does not seem to make sense. Maybe only if two squid processes were running, one unconfined and one confined, that were conflicting.
Perhaps squid was first run unconfined, creating /var/run/squid.pid that was var_run_t, then run again using the initscript, causing the denial when trying to access the pidfile?
Paul.
Yes that is was i think happened.
selinux@lists.fedoraproject.org