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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
