8:17 a.m.
Classification: UNCLASSIFIED
Caveats: NONE
Background info: running RHEL6 with the latest updates, so
selinux-policy-targeted-3.7.19-231.el6_5.3.noarch.
When moving from Permissive to Enforcing, two scripts in /etc/cron.daily that use the bash
"." operator to include a functions file can no longer do so. The functions
file sets $PATH and other environment variables, so subsequent commands in the scripts
fail.
Interestingly, when run out of root's crontab, the scripts work just fine. The
context when doing that (gathered by placing id -Z in the script) is:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Not sure why; the script itself isn't unlabeled:
bash-4.1# ls -lZ /usr/local/sbin/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0 /usr/local/sbin/puppet-state
When run from /etc/cron.daily (or cron.hourly, where I placed a copy for faster testing),
the context is:
system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
bash-4.1# ls -lZ /etc/cron.hourly/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0 /etc/cron.hourly/puppet-state
The exact command in question it's failing to run is:
. /opt/puppet/scripts/functions
Which is labeled thusly:
bash-4.1# ls -lZ /opt/puppet/scripts/functions
-r-x------. root root unconfined_u:object_r:usr_t:s0 /opt/puppet/scripts/functions
In either Enforcing or Permissive, I wasn't seeing anything that looked relevant, so I
ran semodule -DB. This is the only thing cron-related, but (and I'm not very
experienced with SELinux, so maybe I'm missing something) that doesn't seem like
it:
bash-4.1# cat /var/log/audit/audit.log-20140814 | grep cron | audit2allow -w
type=AVC msg=audit(1407915503.212:155119): avc: denied { rlimitinh } for pid=26239
comm="prelink" scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
type=AVC msg=audit(1407915503.212:155119): avc: denied { siginh } for pid=26239
comm="prelink" scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this
access.
I suppose we could run them out of root's crontab, but they're easier to manage in
cron.daily, and I'd like to solve the problem. Any assistance is greatly appreciated.
A search of the list archives didn't turn up this issue; sorry if I've missed
it.
--
Ray Shaw (Contractor, STG)
Army Research Laboratory
Classification: UNCLASSIFIED
Caveats: NONE
8:43 a.m.
There are a few ways that you could speed up your troubleshooting:
1. Schedule your job with a file in /etc/cron.d to run the script in
/etc/cron.daily on a much more frequent interval
2. Use runcon to run your script with the same context that crond would
have when executing. For example:
runcon -u system_u -r system_r -t system_cronjob_t
/etc/cron.daily/logrotate
After you run the scripts (or at the end of the scripts), can you run this
and provide the raw audit messages?
ausearch -m avc -ts recent
On Thu, Aug 14, 2014 at 8:17 AM, Shaw, Ray V CTR USARMY ARL (US) <
ray.v.shaw.ctr(a)mail.mil> wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Background info: running RHEL6 with the latest updates, so
selinux-policy-targeted-3.7.19-231.el6_5.3.noarch.
When moving from Permissive to Enforcing, two scripts in /etc/cron.daily
that use the bash "." operator to include a functions file can no longer do
so. The functions file sets $PATH and other environment variables, so
subsequent commands in the scripts fail.
Interestingly, when run out of root's crontab, the scripts work just fine.
The context when doing that (gathered by placing id -Z in the script) is:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Not sure why; the script itself isn't unlabeled:
bash-4.1# ls -lZ /usr/local/sbin/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0
/usr/local/sbin/puppet-state
When run from /etc/cron.daily (or cron.hourly, where I placed a copy for
faster testing), the context is:
system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
bash-4.1# ls -lZ /etc/cron.hourly/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0
/etc/cron.hourly/puppet-state
The exact command in question it's failing to run is:
. /opt/puppet/scripts/functions
Which is labeled thusly:
bash-4.1# ls -lZ /opt/puppet/scripts/functions
-r-x------. root root unconfined_u:object_r:usr_t:s0
/opt/puppet/scripts/functions
In either Enforcing or Permissive, I wasn't seeing anything that looked
relevant, so I ran semodule -DB. This is the only thing cron-related, but
(and I'm not very experienced with SELinux, so maybe I'm missing something)
that doesn't seem like it:
bash-4.1# cat /var/log/audit/audit.log-20140814 | grep cron | audit2allow
-w
type=AVC msg=audit(1407915503.212:155119): avc: denied { rlimitinh } for
pid=26239 comm="prelink"
scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to
allow this access.
type=AVC msg=audit(1407915503.212:155119): avc: denied { siginh } for
pid=26239 comm="prelink"
scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to
allow this access.
I suppose we could run them out of root's crontab, but they're easier to
manage in cron.daily, and I'd like to solve the problem. Any assistance is
greatly appreciated. A search of the list archives didn't turn up this
issue; sorry if I've missed it.
--
Ray Shaw (Contractor, STG)
Army Research Laboratory
Classification: UNCLASSIFIED
Caveats: NONE
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
--
Jeremy Young <jrm16020(a)gmail.com>, M.S., RHCSA
9:27 a.m.
Classification: UNCLASSIFIED
Caveats: NONE
Attached. I did notice some cron + bash related messages, so hopefully the
answer is in there. They seemed to refer to our su wrapper, which I admit
could be the problem, if cron is calling su in some way. I believe it's
needed for some form of 2-factor authentication when using su. It was
previously labeled as unconfined; yesterday I changed the labeling to match
that of the su binary in the original RHEL6 coreutils package, but that didn't
seem to help. I also tried reinstalling coreutils and using the standard su
binary, but that didn't help either (I just get the same messages for "su"
instead of "su.real").
bash-4.1# ls -lZ /bin/su*
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0 /bin/su ->
/bin/su.wrapper
-r-xr-xr-x. root root system_u:object_r:su_exec_t:s0 /bin/su.real
-r-sr-xr-x. root root system_u:object_r:su_exec_t:s0 /bin/su.wrapper
The attached file shows the commands run both with and without dontaudit
disabled:
10:12:30 runcon -u system_u -r system_r -t system_cronjob_t
/etc/cron.daily/puppet-state
10:14:25 semodule -B
10:15:06 runcon -u system_u -r system_r -t system_cronjob_t
/etc/cron.daily/puppet-state
10:15:16 ausearch -m avc -ts recent &> /root/avc3.txt
--
Ray Shaw (Contractor, STG)
Army Research Laboratory
CIO, Unix Support
-----Original Message-----
From: Jeremy Young [mailto:jrm16020@gmail.com]
Sent: Thursday, August 14, 2014 9:43 AM
To: Shaw, Ray V CTR USARMY ARL (US)
Cc: selinux(a)lists.fedoraproject.org
Subject: Re: cron issues with bash source (UNCLASSIFIED)
There are a few ways that you could speed up your troubleshooting:
1. Schedule your job with a file in /etc/cron.d to run the script in
/etc/cron.daily on a much more frequent interval 2. Use runcon to run
your script with the same context that crond would have when executing.
For example:
runcon -u system_u -r system_r -t system_cronjob_t
/etc/cron.daily/logrotate
After you run the scripts (or at the end of the scripts), can you run
this and provide the raw audit messages?
ausearch -m avc -ts recent
On Thu, Aug 14, 2014 at 8:17 AM, Shaw, Ray V CTR USARMY ARL (US)
<ray.v.shaw.ctr(a)mail.mil> wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Background info: running RHEL6 with the latest updates, so
selinux-policy-targeted-3.7.19-231.el6_5.3.noarch.
When moving from Permissive to Enforcing, two scripts in
/etc/cron.daily that use the bash "." operator to include a functions
file can no longer do so. The functions file sets $PATH and other
environment variables, so subsequent commands in the scripts fail.
Interestingly, when run out of root's crontab, the scripts work
just fine. The context when doing that (gathered by placing id -Z in
the script) is:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Not sure why; the script itself isn't unlabeled:
bash-4.1# ls -lZ /usr/local/sbin/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0
/usr/local/sbin/puppet-state
When run from /etc/cron.daily (or cron.hourly, where I placed a
copy for faster testing), the context is:
system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
bash-4.1# ls -lZ /etc/cron.hourly/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0
/etc/cron.hourly/puppet-state
The exact command in question it's failing to run is:
. /opt/puppet/scripts/functions
Which is labeled thusly:
bash-4.1# ls -lZ /opt/puppet/scripts/functions
-r-x------. root root unconfined_u:object_r:usr_t:s0
/opt/puppet/scripts/functions
In either Enforcing or Permissive, I wasn't seeing anything that
looked relevant, so I ran semodule -DB. This is the only thing cron-
related, but (and I'm not very experienced with SELinux, so maybe I'm
missing something) that doesn't seem like it:
bash-4.1# cat /var/log/audit/audit.log-20140814 | grep cron |
audit2allow -w
type=AVC msg=audit(1407915503.212:155119): avc: denied {
rlimitinh } for pid=26239 comm="prelink"
scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable
module to allow this access.
type=AVC msg=audit(1407915503.212:155119): avc: denied { siginh
} for pid=26239 comm="prelink"
scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable
module to allow this access.
I suppose we could run them out of root's crontab, but they're
easier to manage in cron.daily, and I'd like to solve the problem. Any
assistance is greatly appreciated. A search of the list archives
didn't turn up this issue; sorry if I've missed it.
--
Ray Shaw (Contractor, STG)
Army Research Laboratory
Classification: UNCLASSIFIED
Caveats: NONE
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
--
Jeremy Young <mailto:jrm16020@gmail.com> , M.S., RHCSA
Classification: UNCLASSIFIED
Caveats: NONE
12:17 p.m.
Can you share the script, assuming that it's not classified? It may help
provide some context for the su question.
You can get some of your noise to go away by relabeling your syslog port:
semanage port -a -t syslogd_port_t -p tcp 601
A lot of the denials in your log are don't audited by default, but none of
them seem related to sourcing your functions file.
Finally, are the functions shared between scripts? If you include the
pertinent functions in the puppet-state script, do you continue to have
issues?
On Thu, Aug 14, 2014 at 9:27 AM, Shaw, Ray V CTR USARMY ARL (US) <
ray.v.shaw.ctr(a)mail.mil> wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Attached. I did notice some cron + bash related messages, so hopefully the
answer is in there. They seemed to refer to our su wrapper, which I admit
could be the problem, if cron is calling su in some way. I believe it's
needed for some form of 2-factor authentication when using su. It was
previously labeled as unconfined; yesterday I changed the labeling to match
that of the su binary in the original RHEL6 coreutils package, but that
didn't
seem to help. I also tried reinstalling coreutils and using the standard
su
binary, but that didn't help either (I just get the same messages for "su"
instead of "su.real").
bash-4.1# ls -lZ /bin/su*
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0 /bin/su ->
/bin/su.wrapper
-r-xr-xr-x. root root system_u:object_r:su_exec_t:s0 /bin/su.real
-r-sr-xr-x. root root system_u:object_r:su_exec_t:s0 /bin/su.wrapper
The attached file shows the commands run both with and without dontaudit
disabled:
10:12:30 runcon -u system_u -r system_r -t system_cronjob_t
/etc/cron.daily/puppet-state
10:14:25 semodule -B
10:15:06 runcon -u system_u -r system_r -t system_cronjob_t
/etc/cron.daily/puppet-state
10:15:16 ausearch -m avc -ts recent &> /root/avc3.txt
--
Ray Shaw (Contractor, STG)
Army Research Laboratory
CIO, Unix Support
> -----Original Message-----
> From: Jeremy Young [mailto:jrm16020@gmail.com]
> Sent: Thursday, August 14, 2014 9:43 AM
> To: Shaw, Ray V CTR USARMY ARL (US)
> Cc: selinux(a)lists.fedoraproject.org
> Subject: Re: cron issues with bash source (UNCLASSIFIED)
>
> There are a few ways that you could speed up your troubleshooting:
>
> 1. Schedule your job with a file in /etc/cron.d to run the script in
> /etc/cron.daily on a much more frequent interval 2. Use runcon to run
> your script with the same context that crond would have when executing.
> For example:
> runcon -u system_u -r system_r -t system_cronjob_t
> /etc/cron.daily/logrotate
>
> After you run the scripts (or at the end of the scripts), can you run
> this and provide the raw audit messages?
> ausearch -m avc -ts recent
>
>
> On Thu, Aug 14, 2014 at 8:17 AM, Shaw, Ray V CTR USARMY ARL (US)
> <ray.v.shaw.ctr(a)mail.mil> wrote:
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Background info: running RHEL6 with the latest updates, so
> selinux-policy-targeted-3.7.19-231.el6_5.3.noarch.
>
> When moving from Permissive to Enforcing, two scripts in
> /etc/cron.daily that use the bash "." operator to include a functions
> file can no longer do so. The functions file sets $PATH and other
> environment variables, so subsequent commands in the scripts fail.
>
> Interestingly, when run out of root's crontab, the scripts work
> just fine. The context when doing that (gathered by placing id -Z in
> the script) is:
>
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>
> Not sure why; the script itself isn't unlabeled:
>
> bash-4.1# ls -lZ /usr/local/sbin/puppet-state
> -rwx------. root root system_u:object_r:bin_t:s0
> /usr/local/sbin/puppet-state
>
> When run from /etc/cron.daily (or cron.hourly, where I placed a
> copy for faster testing), the context is:
>
> system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
>
> bash-4.1# ls -lZ /etc/cron.hourly/puppet-state
> -rwx------. root root system_u:object_r:bin_t:s0
> /etc/cron.hourly/puppet-state
>
> The exact command in question it's failing to run is:
>
> . /opt/puppet/scripts/functions
>
> Which is labeled thusly:
>
> bash-4.1# ls -lZ /opt/puppet/scripts/functions
> -r-x------. root root unconfined_u:object_r:usr_t:s0
> /opt/puppet/scripts/functions
>
> In either Enforcing or Permissive, I wasn't seeing anything that
> looked relevant, so I ran semodule -DB. This is the only thing cron-
> related, but (and I'm not very experienced with SELinux, so maybe I'm
> missing something) that doesn't seem like it:
>
> bash-4.1# cat /var/log/audit/audit.log-20140814 | grep cron |
> audit2allow -w
> type=AVC msg=audit(1407915503.212:155119): avc: denied {
> rlimitinh } for pid=26239 comm="prelink"
> scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
>
> Was caused by:
> Missing type enforcement (TE) allow rule.
>
> You can use audit2allow to generate a loadable
> module to allow this access.
>
> type=AVC msg=audit(1407915503.212:155119): avc: denied { siginh
> } for pid=26239 comm="prelink"
> scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process
>
> Was caused by:
> Missing type enforcement (TE) allow rule.
>
> You can use audit2allow to generate a loadable
> module to allow this access.
>
> I suppose we could run them out of root's crontab, but they're
> easier to manage in cron.daily, and I'd like to solve the problem. Any
> assistance is greatly appreciated. A search of the list archives
> didn't turn up this issue; sorry if I've missed it.
>
> --
> Ray Shaw (Contractor, STG)
> Army Research Laboratory
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
>
>
> --
>
> Jeremy Young <mailto:jrm16020@gmail.com> , M.S., RHCSA
>
>
Classification: UNCLASSIFIED
Caveats: NONE
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
--
Jeremy Young <jrm16020(a)gmail.com>, M.S., RHCSA
3536
days inactive
3536
days old
selinux@lists.fedoraproject.org
3 comments
2 participants
participants (2)
-
Jeremy Young -
Shaw, Ray V CTR USARMY RDECOM ARL (US)