On 01/18/2013 02:53 AM, Dominick Grift wrote:
> On Thu, 2013-01-17 at 18:11 -0500, Jean-David Beyer wrote:
>> I have been running Red Hat Enterprise Linux since 2004, starting with
>> RHEL 3. Later I upgraded to RHEL 5. When I needed a new computer, I got
>> RHEL 6 to run on it.
>>
>> RHEL 6 runs with SELinux turned on by default and it is presenting me
>> with oneproblem, but my /var/log/messages file indicates I have _a lot_
>> of others.
>>
>> Now according to Red Hat's documentation, I should report these as bugs,
>> but that seems a bit extreme if it is just a misconfiguration problem.
>>
>>> Missing Type Enforcement rules are usually caused by bugs in SELinux
>>> policy, and should be reported in Red Hat Bugzilla. For Red Hat
>>> Enterprise Linux, create bugs against the Red Hat Enterprise Linux
>>> product, and select the selinux-policy component. Include the output
>>> of the audit2allow -w -a and audit2allow -a commands in such bug
>>> reports.
>>
>> Should I really do that? And if so, just how? How do I specify the
>> problem in a way to be useful?
>>
>> One problem is that I have a shell script, run by cron that sends an
>> email with mailx to me (on the same machine). That means it is run by
>> root. And the mail fails when cron runs it. It is adding an attachment
>> and SELinux says it is denied. Now when I run it myself, but logged in
>> as root, the e-mail works. I do not specifically want to solve that
>> problem here, but I do need to now how to change the system policy file,
>> wherever it is, so I do not need to continually make little ones, say by
>> running stuff like this:
>>
>> # grep boinc_client /var/log/audit/audit.log | audit2allow -M myboinc
>> # semodule -i myboinc.pp
>>
>> I also wish to make the change, if they are really required, permanent.
>>
>> Any advice?
>
> 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
> 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.
>
> 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.
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.
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.
>
> 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
