Hello All,
Does anyone happen to be running Quagga on CentOS 5 with SELinux in enforcing mode? Have you had to create SELinux policies or did it "just work" out of the box?
(I'll get around to building this out on CentOS 6 as well.)
I'm simply trying to write my config (for the zebra daemon) and it can't be written...
Looks like this bug from Fedora 8 in 2008 [0] remains (or one similar to it spawned). And the problem was present in 2010 per the CentOS forums [1].
I'm not opposed to creating SELinux policies and I may do just that (or run around in Permissive mode!). But it'd be awesome if upstream included policies for quagga since quagga is software they package.
Maybe Dan Walsh will hop in on this. ;-)
[0] https://bugzilla.redhat.com/show_bug.cgi?id=429252 [1] https://www.centos.org/forums/viewtopic.php?t=21040
type=AVC msg=audit(1393980136.848:15): avc: denied { add_name } for pid=2646 comm="zebra" name="zebra.conf.CxNsyz" scontext=root:system_r:zebra_t:s0 tcontext=system_u:object_r:zebra_conf_t:s0 tclass=dir type=SYSCALL msg=audit(1393980136.848:15): arch=40000003 syscall=5 success=no exit=-13 a0=8512960 a1=c2 a2=180 a3=1e6a6 items=0 ppid=1 pid=2646 auid=0 uid=92 gid=92 euid=92 suid=92 fsuid=92 egid=92 sgid=92 fsgid=92 tty=(none) ses=1 comm="zebra" exe="/usr/sbin/zebra" subj=root:system_r:zebra_t:s0 key=(null)
~]# ls -Z /etc/quagga/ -rw-r--r-- root root system_u:object_r:zebra_conf_t bgpd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t bgpd.conf.sample2 -rw-r--r-- root root system_u:object_r:zebra_conf_t ospf6d.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ospfd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ripd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ripngd.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t vtysh.conf -rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf.sample -rw------- quagga quagga root:object_r:zebra_conf_t zebra.conf -rw-r--r-- root root system_u:object_r:zebra_conf_t zebra.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t zebra.conf.sav
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/04/2014 07:56 PM, SilverTip257 wrote:
Hello All,
Does anyone happen to be running Quagga on CentOS 5 with SELinux in enforcing mode? Have you had to create SELinux policies or did it "just work" out of the box?
(I'll get around to building this out on CentOS 6 as well.)
I'm simply trying to write my config (for the zebra daemon) and it can't be written...
Looks like this bug from Fedora 8 in 2008 [0] remains (or one similar to it spawned). And the problem was present in 2010 per the CentOS forums [1].
I'm not opposed to creating SELinux policies and I may do just that (or run around in Permissive mode!). But it'd be awesome if upstream included policies for quagga since quagga is software they package.
Maybe Dan Walsh will hop in on this. ;-)
[0] https://bugzilla.redhat.com/show_bug.cgi?id=429252 [1] https://www.centos.org/forums/viewtopic.php?t=21040
type=AVC msg=audit(1393980136.848:15): avc: denied { add_name } for pid=2646 comm="zebra" name="zebra.conf.CxNsyz" scontext=root:system_r:zebra_t:s0 tcontext=system_u:object_r:zebra_conf_t:s0 tclass=dir type=SYSCALL msg=audit(1393980136.848:15): arch=40000003 syscall=5 success=no exit=-13 a0=8512960 a1=c2 a2=180 a3=1e6a6 items=0 ppid=1 pid=2646 auid=0 uid=92 gid=92 euid=92 suid=92 fsuid=92 egid=92 sgid=92 fsgid=92 tty=(none) ses=1 comm="zebra" exe="/usr/sbin/zebra" subj=root:system_r:zebra_t:s0 key=(null)
~]# ls -Z /etc/quagga/ -rw-r--r-- root root system_u:object_r:zebra_conf_t bgpd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t bgpd.conf.sample2 -rw-r--r-- root root system_u:object_r:zebra_conf_t ospf6d.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ospfd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ripd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ripngd.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t vtysh.conf -rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf.sample -rw------- quagga quagga root:object_r:zebra_conf_t zebra.conf -rw-r--r-- root root system_u:object_r:zebra_conf_t zebra.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t zebra.conf.sav
Does setsebool -P zebra_write_conf 1
Fix your problem?
On Wed, Mar 5, 2014 at 10:18 AM, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Does setsebool -P zebra_write_conf 1
Fix your problem?
So far I ran: setsebool -P allow_zebra_write_config=1 ( per https://bugzilla.redhat.com/show_bug.cgi?id=429252#c1 )
I'll run your different command this evening and see what I get.
Thanks for pointing out there is a zebra_selinux manpage in your second reply ... I was ignorant to its existence. :-/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/04/2014 07:56 PM, SilverTip257 wrote:
Hello All,
Does anyone happen to be running Quagga on CentOS 5 with SELinux in enforcing mode? Have you had to create SELinux policies or did it "just work" out of the box?
(I'll get around to building this out on CentOS 6 as well.)
I'm simply trying to write my config (for the zebra daemon) and it can't be written...
Looks like this bug from Fedora 8 in 2008 [0] remains (or one similar to it spawned). And the problem was present in 2010 per the CentOS forums [1].
I'm not opposed to creating SELinux policies and I may do just that (or run around in Permissive mode!). But it'd be awesome if upstream included policies for quagga since quagga is software they package.
Maybe Dan Walsh will hop in on this. ;-)
[0] https://bugzilla.redhat.com/show_bug.cgi?id=429252 [1] https://www.centos.org/forums/viewtopic.php?t=21040
type=AVC msg=audit(1393980136.848:15): avc: denied { add_name } for pid=2646 comm="zebra" name="zebra.conf.CxNsyz" scontext=root:system_r:zebra_t:s0 tcontext=system_u:object_r:zebra_conf_t:s0 tclass=dir type=SYSCALL msg=audit(1393980136.848:15): arch=40000003 syscall=5 success=no exit=-13 a0=8512960 a1=c2 a2=180 a3=1e6a6 items=0 ppid=1 pid=2646 auid=0 uid=92 gid=92 euid=92 suid=92 fsuid=92 egid=92 sgid=92 fsgid=92 tty=(none) ses=1 comm="zebra" exe="/usr/sbin/zebra" subj=root:system_r:zebra_t:s0 key=(null)
~]# ls -Z /etc/quagga/ -rw-r--r-- root root system_u:object_r:zebra_conf_t bgpd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t bgpd.conf.sample2 -rw-r--r-- root root system_u:object_r:zebra_conf_t ospf6d.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ospfd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ripd.conf.sample -rw-r--r-- root root system_u:object_r:zebra_conf_t ripngd.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t vtysh.conf -rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf.sample -rw------- quagga quagga root:object_r:zebra_conf_t zebra.conf -rw-r--r-- root root system_u:object_r:zebra_conf_t zebra.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t zebra.conf.sav
man zebra_selinux ... If you want to allow zebra daemon to write it configuration files, you must turn on the zebra_write_config boolean. Disabled by default.
setsebool -P zebra_write_config 1
On Wed, Mar 5, 2014 at 9:19 AM, Daniel J Walsh dwalsh@redhat.com wrote:
man zebra_selinux ... If you want to allow zebra daemon to write it configuration files, you must turn on the zebra_write_config boolean. Disabled by default.
setsebool -P zebra_write_config 1
Is there some global registration facility for selinux context names or are you the only one that knows them all?
On 05/03/2014 19:11, Les Mikesell wrote:
On Wed, Mar 5, 2014 at 9:19 AM, Daniel J Walsh dwalsh@redhat.com wrote:
man zebra_selinux ... If you want to allow zebra daemon to write it configuration files, you must turn on the zebra_write_config boolean. Disabled by default.
setsebool -P zebra_write_config 1Is there some global registration facility for selinux context names or are you the only one that knows them all?
You can see all the se booleans by running getsebool -a
Tris
************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@bgfl.org
The views expressed within this email are those of the individual, and not necessarily those of the organisation *************************************************************
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/05/2014 02:11 PM, Les Mikesell wrote:
On Wed, Mar 5, 2014 at 9:19 AM, Daniel J Walsh dwalsh@redhat.com wrote:
man zebra_selinux ... If you want to allow zebra daemon to write it configuration files, you must turn on the zebra_write_config boolean. Disabled by default.
setsebool -P zebra_write_config 1
Is there some global registration facility for selinux context names or are you the only one that knows them all?
Don't really know what you mean by that.
getsebool -a
Will list all booleans
semanage boolean -l
Will list them with a short description.
man DOMAIN_selinux
Is available for over 1000 applications.
system-config-selinux
Also can list booleans.
If you want to look at all the types available you can use seinfo. seinfo -t for example.
If you want to look at all allow rules, sesearch will tell you.
On Thu, Mar 6, 2014 at 8:02 AM, Daniel J Walsh dwalsh@redhat.com wrote:
setsebool -P zebra_write_config 1
Is there some global registration facility for selinux context names or are you the only one that knows them all?
Don't really know what you mean by that.
I mean, if different people make up new names for use in different new applications, what keeps them from colliding/conflicting when the packaged settings are later installed on the same computer?
getsebool -a
Will list all booleans
semanage boolean -l
Will list them with a short description.
All in the world, or all that have been created for currently installed packages? Is this as bad as rpm packaging where any two different sources are likely to conflict in name and/or contents?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/06/2014 10:39 AM, Les Mikesell wrote:
On Thu, Mar 6, 2014 at 8:02 AM, Daniel J Walsh dwalsh@redhat.com wrote:
setsebool -P zebra_write_config 1
Is there some global registration facility for selinux context names or are you the only one that knows them all?
Don't really know what you mean by that.
I mean, if different people make up new names for use in different new applications, what keeps them from colliding/conflicting when the packaged settings are later installed on the same computer?
getsebool -a
Will list all booleans
semanage boolean -l
Will list them with a short description.
All in the world, or all that have been created for currently installed packages? Is this as bad as rpm packaging where any two different sources are likely to conflict in name and/or contents?
Well we have not had this problem over the years, since most people upstream their policy. Right now if a customer installed a policy file which conflicted with the base policy, it will get overwritten. I guess if they did it will rpm then it would get you an RPM error/warning.
On Thu, Mar 6, 2014 at 11:03 AM, Daniel J Walsh dwalsh@redhat.com wrote:
All in the world, or all that have been created for currently installed packages? Is this as bad as rpm packaging where any two different sources are likely to conflict in name and/or contents?
Well we have not had this problem over the years, since most people upstream their policy. Right now if a customer installed a policy file which conflicted with the base policy, it will get overwritten. I guess if they did it will rpm then it would get you an RPM error/warning.
What does 'upstream' mean in the context of packages that aren't included in RHEL base or EPEL? It just seems like a giant list of global variables without any structure or namespace management.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/06/2014 01:15 PM, Les Mikesell wrote:
On Thu, Mar 6, 2014 at 11:03 AM, Daniel J Walsh dwalsh@redhat.com wrote:
All in the world, or all that have been created for currently installed packages? Is this as bad as rpm packaging where any two different sources are likely to conflict in name and/or contents?
Well we have not had this problem over the years, since most people upstream their policy. Right now if a customer installed a policy file which conflicted with the base policy, it will get overwritten. I guess if they did it will rpm then it would get you an RPM error/warning.
What does 'upstream' mean in the context of packages that aren't included in RHEL base or EPEL? It just seems like a giant list of global variables without any structure or namespace management.
Not sure what you mean but these are files on a file system, Which I guess you define as a giant list of global variables. The names tend to match the name of the package they are confining. sshd.pp confined sshd for example.
selinux-policy is a big upstream project hosted at tresys, where you would discover the conflicting names.
We don't tend to add few new policy packages to a major rhel release.
So it is unlikely that we would have a conflict with a name in an Enterprise release.
On Thu, Mar 6, 2014 at 2:53 PM, Daniel J Walsh dwalsh@redhat.com wrote:
Not sure what you mean but these are files on a file system, Which I guess you define as a giant list of global variables.
Yes, in the sense that there can only be one of each. And if you intend for it to be widely used there might someday be a lot of them.
The names tend to match the name of the package they are confining. sshd.pp confined sshd for example.
selinux-policy is a big upstream project hosted at tresys, where you would discover the conflicting names.
We don't tend to add few new policy packages to a major rhel release.
So it is unlikely that we would have a conflict with a name in an Enterprise release.
Of course you won't have conflicts "in" an enterprise release, just like you don't have conflicts in rpm package names and contents - because you have someone managing that release.. But for users _running_ the enterprise release and adding other things run into those conflicts with packages all the time. Contexts/boolean names aren't quite as common as 3rd party packages, but shouldn't there be a plan for them to scale?
On Wed, Mar 5, 2014 at 10:19 AM, Daniel J Walsh dwalsh@redhat.com wrote:
man zebra_selinux
Thank you for the quick reply.
~]# man zebra_selinux No manual entry for zebra_selinux
This is a rather basic (headless) install of CentOS 5.10 from the netinstall ISO. I haven't ripped out any default selinux pieces, so should I really be missing that manpage?
~]# cat /etc/*ele* cat: /etc/lsb-release.d: Is a directory CentOS release 5.10 (Final)
~]# apropos selinux | egrep 'zebra|quagga'
If I remove the pipe to egrep, I do see squid_selinux for example.
... If you want to allow zebra daemon to write it configuration files, you must turn on the zebra_write_config boolean. Disabled by default.
setsebool -P zebra_write_config 1
// before ~]# getsebool -a | grep zebra allow_zebra_write_config --> on zebra_disable_trans --> off
Apparently the command from the Bugzilla ticket I linked to earlier took and already had allow_zebra_write_config enabled. setsebool -P allow_zebra_write_config=1
// trying to set that selinux boolean comes back with ~]# setsebool -P zebra_write_config 1 libsemanage.dbase_llist_set: record not found in the database libsemanage.dbase_llist_set: could not set record value Could not change boolean zebra_write_config Could not change policy booleans
On an selinux, but different topic... I had to modify the user (role and type were right) to allow dnsmasq to write to /var/log/dnsmasq.log ~]# chcon -v --user=system_u --role=object_r --type=var_log_t /var/log/dnsmasq.log This may or may not be the best/proper way, but appears to have fixed the dnsmasq logging + selinux clash.
And now to apply that to my quagga/zebra + selinux situation... // before ~]# ls -Z /etc/quagga/ | egrep '(zebra|vtysh).conf' -rw-r----- quagga quaggavt root:object_r:zebra_conf_t vtysh.conf -rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf.sample -rw------- quagga quagga root:object_r:zebra_conf_t zebra.conf -rw-r--r-- root root system_u:object_r:zebra_conf_t zebra.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t zebra.conf.sav
~]# chcon -v --user=system_u /etc/quagga/vtysh.conf /etc/quagga/zebra.conf /etc/quagga/zebra.conf.sav
// after ~]# ls -Z /etc/quagga/ | egrep '(zebra|vtysh).conf' -rw-r----- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf -rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf.sample -rw------- quagga quagga system_u:object_r:zebra_conf_t zebra.conf -rw-r--r-- root root system_u:object_r:zebra_conf_t zebra.conf.sample -rw-r----- quagga quaggavt system_u:object_r:zebra_conf_t zebra.conf.sav
// but no dice ... # write Building Configuration... Can't open configuration file /etc/quagga/zebra.conf.ZHwkuk. [OK]
~]# tail /var/log/audit/audit.log | grep zebra | audit2why ... type=AVC msg=audit(1394150156.203:30): avc: denied { add_name } for pid=3111 comm="zebra" name="zebra.conf.fT434c" scontext=root:system_r:zebra_t:s0 tcontext=system_u:object_r:zebra_conf_t:s0 tclass=dir Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input.
~]# tail /var/log/audit/audit.log | grep zebra | audit2allow
#============= zebra_t ============== allow zebra_t zebra_conf_t:dir add_name;
What am I doing wrong here? ( missing manpage , still AVC denied )
I'm learning a thing or two about SELinux with each bump in the road it presents to me. Thanks for the help and for bearing with me. ;)
From: SilverTip257 silvertip257@gmail.com
On Wed, Mar 5, 2014 at 10:19 AM, Daniel J Walsh dwalsh@redhat.com wrote:
man zebra_selinux
~]# man zebra_selinux No manual entry for zebra_selinux
This man page seems to be in selinux-policy-doc package for CentOS 6... # yum whatprovides *zebra_selinux* ... selinux-policy-doc-3.7.19-231.el6.noarch : SELinux policy documentation Repo : base Matched from: Filename : /usr/share/man/man8/zebra_selinux.8.gz
JD
On Fri, Mar 7, 2014 at 5:16 AM, John Doe jdmls@yahoo.com wrote:
From: SilverTip257 silvertip257@gmail.com
On Wed, Mar 5, 2014 at 10:19 AM, Daniel J Walsh dwalsh@redhat.com
wrote:
man zebra_selinux
~]# man zebra_selinux No manual entry for zebra_selinux
This man page seems to be in selinux-policy-doc package for CentOS 6...
I'm on CentOS 5.10 on the system in question. I did try searching for packages prior to sending the message you responded to.
# yum whatprovides *zebra_selinux* ... selinux-policy-doc-3.7.19-231.el6.noarch : SELinux policy documentation Repo : base Matched from: Filename : /usr/share/man/man8/zebra_selinux.8.gz
Here's a search from 5.10...
~]$ yum whatprovides *zebra_selinux* ... No Matches found
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/06/2014 07:07 PM, SilverTip257 wrote:
On Wed, Mar 5, 2014 at 10:19 AM, Daniel J Walsh dwalsh@redhat.com wrote:
man zebra_selinux
Thank you for the quick reply.
~]# man zebra_selinux No manual entry for zebra_selinux
This is a rather basic (headless) install of CentOS 5.10 from the netinstall ISO. I haven't ripped out any default selinux pieces, so should I really be missing that manpage?
~]# cat /etc/*ele* cat: /etc/lsb-release.d: Is a directory CentOS release 5.10 (Final)
~]# apropos selinux | egrep 'zebra|quagga'
If I remove the pipe to egrep, I do see squid_selinux for example.
... If you want to allow zebra daemon to write it configuration files, you must turn on the zebra_write_config boolean. Disabled by default.
setsebool -P zebra_write_config 1
// before ~]# getsebool -a | grep zebra allow_zebra_write_config --> on zebra_disable_trans --> off
Apparently the command from the Bugzilla ticket I linked to earlier took and already had allow_zebra_write_config enabled. setsebool -P allow_zebra_write_config=1
// trying to set that selinux boolean comes back with ~]# setsebool -P zebra_write_config 1 libsemanage.dbase_llist_set: record not found in the database libsemanage.dbase_llist_set: could not set record value Could not change boolean zebra_write_config Could not change policy booleans
On an selinux, but different topic... I had to modify the user (role and type were right) to allow dnsmasq to write to /var/log/dnsmasq.log ~]# chcon -v --user=system_u --role=object_r --type=var_log_t /var/log/dnsmasq.log This may or may not be the best/proper way, but appears to have fixed the dnsmasq logging + selinux clash.
And now to apply that to my quagga/zebra + selinux situation... // before ~]# ls -Z /etc/quagga/ | egrep '(zebra|vtysh).conf' -rw-r----- quagga quaggavt root:object_r:zebra_conf_t vtysh.conf -rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf.sample -rw------- quagga quagga root:object_r:zebra_conf_t zebra.conf -rw-r--r-- root root system_u:object_r:zebra_conf_t zebra.conf.sample -rw-r----- quagga quaggavt root:object_r:zebra_conf_t zebra.conf.sav
~]# chcon -v --user=system_u /etc/quagga/vtysh.conf /etc/quagga/zebra.conf /etc/quagga/zebra.conf.sav
// after ~]# ls -Z /etc/quagga/ | egrep '(zebra|vtysh).conf' -rw-r----- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf -rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf.sample -rw------- quagga quagga system_u:object_r:zebra_conf_t zebra.conf -rw-r--r-- root root system_u:object_r:zebra_conf_t zebra.conf.sample -rw-r----- quagga quaggavt system_u:object_r:zebra_conf_t zebra.conf.sav
// but no dice ... # write Building Configuration... Can't open configuration file /etc/quagga/zebra.conf.ZHwkuk. [OK]
~]# tail /var/log/audit/audit.log | grep zebra | audit2why ... type=AVC msg=audit(1394150156.203:30): avc: denied { add_name } for pid=3111 comm="zebra" name="zebra.conf.fT434c" scontext=root:system_r:zebra_t:s0 tcontext=system_u:object_r:zebra_conf_t:s0 tclass=dir Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input.
~]# tail /var/log/audit/audit.log | grep zebra | audit2allow
#============= zebra_t ============== allow zebra_t zebra_conf_t:dir add_name;
What am I doing wrong here? ( missing manpage , still AVC denied )
I'm learning a thing or two about SELinux with each bump in the road it presents to me. Thanks for the help and for bearing with me. ;)
Introduced in RHEL6 not in Rhel5 sorry
On Thu, Mar 6, 2014 at 7:07 PM, SilverTip257 silvertip257@gmail.com wrote:
On Wed, Mar 5, 2014 at 10:19 AM, Daniel J Walsh dwalsh@redhat.com wrote:
... If you want to allow zebra daemon to write it configuration files, you must turn on the zebra_write_config boolean. Disabled by default.
setsebool -P zebra_write_config 1// before ~]# getsebool -a | grep zebra allow_zebra_write_config --> on zebra_disable_trans --> off
Apparently the command from the Bugzilla ticket I linked to earlier took and already had allow_zebra_write_config enabled. setsebool -P allow_zebra_write_config=1
// trying to set that selinux boolean comes back with ~]# setsebool -P zebra_write_config 1 libsemanage.dbase_llist_set: record not found in the database libsemanage.dbase_llist_set: could not set record value Could not change boolean zebra_write_config Could not change policy booleans
* What should I try next after this failure?
~]# tail /var/log/audit/audit.log | grep zebra | audit2why ... type=AVC msg=audit(1394150156.203:30): avc: denied { add_name } for pid=3111 comm="zebra" name="zebra.conf.fT434c" scontext=root:system_r:zebra_t:s0 tcontext=system_u:object_r:zebra_conf_t:s0 tclass=dir Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input.
~]# tail /var/log/audit/audit.log | grep zebra | audit2allow
#============= zebra_t ============== allow zebra_t zebra_conf_t:dir add_name;
* So I'm at the point where I may just as well create a custom policy file?
I plan on following the steps on the wiki (unless there's a better source/write-up). http://wiki.centos.org/HowTos/SELinux
Looks like this will be a fun one ... I'll have rules for each routing daemon to create. [At least that's the impression I got from mailing lists/bug tickets.]
Thanks,
-
Daniel J Walsh -
John Doe -
Les Mikesell -
SilverTip257 -
Tris Hoar