Hi,
I'm currently re-packaging BackupPC[1], a perl backup software server.
As BackupPC need to use, for example, rsync or tar to backup itself, wich cause SELinux denies. There also is a CGI interface to manage backups/restore and config.
As I'm not at all a SELinux guru, I've used 'audit2allow' to create a selinux policy module included in my specfile, but I don't know if this is the good way, and even if my policy module should causes issues...
I'd like you to have advices related to SELinux integration in this RPM file. I'll put online actual policy file[2], as I use it in the specfile[3] I'd also like opinions on the best way to include an SELinux policy for this software.
Regards, Johan
[1] http://backuppc.sourceforge.net [2] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te [3] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.spec
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johan Cwiklinski wrote:
Hi,
I'm currently re-packaging BackupPC[1], a perl backup software server.
As BackupPC need to use, for example, rsync or tar to backup itself, wich cause SELinux denies. There also is a CGI interface to manage backups/restore and config.
As I'm not at all a SELinux guru, I've used 'audit2allow' to create a selinux policy module included in my specfile, but I don't know if this is the good way, and even if my policy module should causes issues...
I'd like you to have advices related to SELinux integration in this RPM file. I'll put online actual policy file[2], as I use it in the specfile[3] I'd also like opinions on the best way to include an SELinux policy for this software.
Regards, Johan
[1] http://backuppc.sourceforge.net [2] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te [3] http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.spec
No alot of these rules are not good. Could you attach the audit log you used to create this.
You probably need a context for this
allow httpd_t etc_t:dir write; and these allow httpd_t usr_t:dir { write add_name }; allow httpd_t usr_t:file { write create };
Could be as simple as
chcon -t httpd_sys_content_rw_t PATHTODIR
I take it this is the socket file that BackupPC is creating. I think you need a policy for this, and then BackupPC could label it appropriately and allow httpd to communicate with it.
allow httpd_t initrc_t:unix_stream_socket connectto; allow httpd_t var_log_t:sock_file write;
Not sure what these are either.
allow httpd_t httpd_log_t:sock_file write; allow httpd_t httpd_sys_content_t:sock_file write;
Hello,
First of all, thanks for your advices.
It seems that I've not used the right approach for this policy module. I was using the following :
grep http /var/log/audit/audit.log | audit2allow -M mybackuppc
But this command also catches SELinux denies which are not relevant to BackupPC.
So, I've restarted from scratch, and now use : audit2allow -m BackupPC -l -i /var/log/audit/audit.log > BackupPC.te
Which only takes the latests entries.
This way, I've removed some entries I did not understand (such as iso9660_t), and were not appropriate here.
Daniel J Walsh a écrit :
No alot of these rules are not good. Could you attach the audit log you used to create this.
These rules were build on two different machines (my laptop and the one were BackupPC is installed for backups). So as I've rebuild my rules from scratch, the log file is available on my web server (see links below).
You probably need a context for this
allow httpd_t etc_t:dir write; and these allow httpd_t usr_t:dir { write add_name }; allow httpd_t usr_t:file { write create };
Could be as simple as
chcon -t httpd_sys_content_rw_t PATHTODIR
These one gives me an invalid argument... I've used "httpd_sys_script_rw_t" instead, am I right ? Also, I were able to remove these three 'allow' entries from my .te and put only the context in .fc file.
I take it this is the socket file that BackupPC is creating. I think you need a policy for this, and then BackupPC could label it appropriately and allow httpd to communicate with it.
allow httpd_t initrc_t:unix_stream_socket connectto; allow httpd_t var_log_t:sock_file write;
Indeed, these ones are for the .sock file BackupPC creates at startup. I don't understand what exactly you mean by 'a policy for this'...
Not sure what these are either.
allow httpd_t httpd_log_t:sock_file write; allow httpd_t httpd_sys_content_t:sock_file write;
It's only a mistake, I had first to put 'sock_file write' for the .sock file, and then I've changed its context. Doing this, the first rule becomes obsolete, and audit2allow gave me the second...
New file are here : - audit.log : http://odysseus.x-tnd.be/fedora/backuppc/audit.log - .te file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te - .fc file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.fc - old .te and .fc (from my preceding message) : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te.old - spec file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.spec
All seems to work correctly with these rules, I wish I made no mistakes this time... :-)
Regards, Johan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johan Cwiklinski wrote:
Hello,
First of all, thanks for your advices.
It seems that I've not used the right approach for this policy module. I was using the following :
grep http /var/log/audit/audit.log | audit2allow -M mybackuppc
But this command also catches SELinux denies which are not relevant to BackupPC.
So, I've restarted from scratch, and now use : audit2allow -m BackupPC -l -i /var/log/audit/audit.log > BackupPC.te
Which only takes the latests entries.
This way, I've removed some entries I did not understand (such as iso9660_t), and were not appropriate here.
Daniel J Walsh a écrit :
No alot of these rules are not good. Could you attach the audit log you used to create this.
These rules were build on two different machines (my laptop and the one were BackupPC is installed for backups). So as I've rebuild my rules from scratch, the log file is available on my web server (see links below).
You probably need a context for this
allow httpd_t etc_t:dir write; and these allow httpd_t usr_t:dir { write add_name }; allow httpd_t usr_t:file { write create };
Could be as simple as
chcon -t httpd_sys_content_rw_t PATHTODIR
These one gives me an invalid argument... I've used "httpd_sys_script_rw_t" instead, am I right ? Also, I were able to remove these three 'allow' entries from my .te and put only the context in .fc file.
Yes, sorry about that.
I take it this is the socket file that BackupPC is creating. I think you need a policy for this, and then BackupPC could label it appropriately and allow httpd to communicate with it.
allow httpd_t initrc_t:unix_stream_socket connectto; allow httpd_t var_log_t:sock_file write;
Indeed, these ones are for the .sock file BackupPC creates at startup. I don't understand what exactly you mean by 'a policy for this'...
Not sure what these are either.
allow httpd_t httpd_log_t:sock_file write; allow httpd_t httpd_sys_content_t:sock_file write;
It's only a mistake, I had first to put 'sock_file write' for the .sock file, and then I've changed its context. Doing this, the first rule becomes obsolete, and audit2allow gave me the second...
New file are here :
- audit.log : http://odysseus.x-tnd.be/fedora/backuppc/audit.log
- .te file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te
- .fc file : http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.fc
- old .te and .fc (from my preceding message) :
http://odysseus.x-tnd.be/fedora/backuppc/BackupPC.te.old
All seems to work correctly with these rules, I wish I made no mistakes this time... :-)
Regards, Johan