On Fri, 2013-01-18 at 06:53 -0500, Jean-David Beyer wrote:
> You could fork the rhel selinux-policy package (you can download
the
> selinux-policy source rpm.
Does this mean I already have the selinux-policy package installed?
$ rpm -qa | grep -i selinux
selinux-policy-targeted-3.7.19-155.el6_3.14.noarch
selinux-policy-3.7.19-155.el6_3.14.noarch <---<<<
libselinux-2.0.94-5.3.el6.i686
libselinux-utils-2.0.94-5.3.el6.x86_64
libselinux-python-2.0.94-5.3.el6.x86_64
libselinux-2.0.94-5.3.el6.x86_64
You but i was refering to the *source* RPM
> use rpmbuild to prep it. then modify it to
> your requirements and repackage it. Then distribute the repackages rpms
I am really new at SELinux, and have made only primitive use of rpm. So
I do not know what you are talking about. What do I need to prep about
that rpm, if it is the correct one? I also do not know how to modify it.
I do not know how or why I would wish to repackage it, and then to whom
would I wish to distribute the repackaged rpnms.
>
I will give you a rough outline but it may be incomplete and have
errors:
Basically download the selinux-policy *source* RPM that is corresponding
to your selinux-policy RPM from for example
ftp.redhat.com
setup up a rpm tree: rpmdev-setuptree
prep the downloaded *source* RPM: rpmbuild --prep
selinux-policy-3.7.19-155.el6_3.14.noarch.src.rpm
Then edit it.
Edit the included spec file.
rebuild the modified policy: rpmbuild -ba
~/rpmbuild/SPECS/selinux-policy.spec
Install the modified RPMS:
sudo rpm -Uvh --force
~/rpmbuild/RPM/noarch/selinux-policy-3.7.19-155.el6_3.14.noarch.rpm
~/rpmbuild/rpm/noarch/selinux-policy-targeted-3.7.19-155.el6_3.14.noarch.rpm
> It is pretty easy to do with a little knowledge about rpm,
> selinux-policy and a vcs.
Well, I have less than a little knowledge of rpm. I can install and
remove them, but that is about it. I know nothing about selinux-policy,
and I do even know what a vcs is.
Version Control System (for example Git)
I just upgraded from RHEL 5 to RHEL 6 (because I got a new 64-bit
machine to replace an old 32-bit machine) and wanted to run it and do
backups with cron (and find and cpio) to my tape drive and to my WD
external disk drives. And it all works except sending mail to myself. It
even works when I send it manually from the console, but fails when
cron, using run-parts, does it. The backups do work. Only the mail
fails. Like this:
Jan 13 03:52:17 DellT7600 kernel: type=1400 audit(1358067137.751:38575):
avc: denied { read } for pid=19533 comm="mailx"
name="report.2013Jan130344" dev=sdb8 ino=525338
scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023
tcontext=system_u:object_r:cron_log_t:s0 tclass=file
I tried to fix it with this:
sealert -l b6766d24-f5e8-4db5-94eb-a153b7e0f35a
SELinux is preventing /bin/mailx from read access on the file
report.2013Jan180316.
***** Plugin catchall (100. confidence) suggests
***************************
If you believe that mailx should be allowed read access on the
report.2013Jan180316 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep mailx /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
DellT7600:root[/var/log]# grep mailx /var/log/audit/audit.log |
audit2allow -M mymail1
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i mymail1.pp
DellT7600:root[/var/log]# semodule -i mymail1.pp
But my guess it will fail tomorrow anyway because the file in question
tomorrow will be a different one, named something like report.2013Jan190316.
That is not a justified assumption. It will likely work tomorrow as well
Similarly, I have a large number of other failures that I have
attempted
to fix in a similar way, and I suspect these fixes are not going to work
in the long term either. Here is one:
Jan 13 03:52:22 DellT7600 kernel: type=1400 audit(1358067142.137:38576):
avc: denied { write } for pid=19269 comm="wcgrid_cep2_qch"
name="C.33.C30H17NO2.01540956.2.bp86.svp.n.pbe0.svp.n.sp" dev=sdb7
ino=268394 scontext=system_u:system_r:boinc_t:s0
tcontext=system_u:object_r:user_home_t:s0 tclass=dir
The names of the programs, that seem to be in the comm= parts of these
messages, change very frequently. Those programs are downloaded
automatically by a constantly running daemon program that gets updated
once in a while, but the programs it downloads and runs change as soon
as one is completed and a new one is obtained. And I just cannot monitor
the message file all the time to keep up with this, so I either need a
very different way of running those programs, a better way to run
SELinux, or just turning SELinux off. I would hate to turn it off.
The above issue seems to me a misconfiguration. But i would need more
information to determine that. The AVC denials gives directions as to
were to look
a command with name wcgrid_cep2_qch wants to write to a directory with
name C.33.C30H17NO2.01540956.2.bp86.svp.n.pbe0.svp.n.sp which is located
on device sdb7 at inode 268394
Use:
find / -inum C.33.C30H17NO2.01540956.2.bp86.svp.n.pbe0.svp.n.sp
to determine that actual full path of this directory. Then determine
whether this is a appropriate location or whether it is labeled properly
>
> I would, however, probably just create a new domain, make that a
> cron_system_entry and write policy to allow that domain what it needs
> rather than extending the generic cron system domain
>
> But replacing the existing cron module is probably also an option.
> semodule allows one to -r (remove) and -d (disable) optional modules
> this enables one to replace them with modified versions
>
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux