10:50 a.m.
On 5/12/20 11:36 AM, Lukas Vrabec wrote:
On 5/12/20 1:31 PM, Robert Moskowitz wrote:
> Lukas,
>
> Failed again last night see the end of this message.
>
> On 5/11/20 9:40 AM, Lukas Vrabec wrote:
>> On 5/11/20 3:19 PM, Robert Moskowitz wrote:
>>> On 5/11/20 9:04 AM, Lukas Vrabec wrote:
>>>> On 5/11/20 2:23 PM, Robert Moskowitz wrote:
>>>>> A little background first.
>>>>>
>>>>> This is for Fedora 32 workstation which does not come with a
>>>>> default MTA
>>>>> and thus there is a slight challenge (ahem) getting CRON's output
into
>>>>> the local mailstore. I don't want to install an MTA (leave why
for
>>>>> Fedora users list discuss) and "procmail -f cron" leaves
out a DATE
>>>>> header. So I wrote my own little script that I put in
>>>>> /usr/local/mycron
>>>>> that takes the output from cron and appends the proper content to
>>>>> /var/spool/mail/$USER.
>>>>>
>>>>> Works fine for my personal crontab, but has selinux problems for
>>>>> logwatch running as root (and probably any other cron task running
as
>>>>> root).
>>>>>
>>>>> So I first got told by selinux troubleshooting that I needed:
>>>>>
>>>>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
>>>>> semodule -X 300 -i my-mycron.pp
>>>>>
>>>>> Which I did. Then after this night's run of logwatch, I see that
I
>>>>> have
>>>>> the selinux troubleshoot icon, but when I look, it is empty? So I
grep
>>>>> messages for logwatch, then grep the time it was running and found
the
>>>>> following:
>>>>>
>>>>> May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is preventing
>>>>> mycron from add_name
>>>>> access on the directory root. For complete SELinux messages run:
>>>>> sealert
>>>>> -l 8eb93a73-c7ff-
>>>>> 42ec-bee1-594d77540808
>>>>> May 11 03:43:19 lx140e python3[121345]: SELinux is preventing mycron
>>>>> from add_name access
>>>>> on the directory root.#012#012***** Plugin catchall (100.
confidence)
>>>>> suggests ********
>>>>> ******************#012#012If you believe that mycron should be
allowed
>>>>> add_name access on
>>>>> the root directory by default.#012Then you should report this as a
>>>>> bug.#012You can generat
>>>>> e a local policy module to allow this access.#012Do#012allow this
>>>>> access
>>>>> for now by execut
>>>>> ing:#012# ausearch -c 'mycron' --raw | audit2allow -M
my-mycron#012#
>>>>> semodule -X 300 -i my
>>>>> -mycron.pp#012
>>>>> May 11 03:43:23 lx140e systemd[1]:
>>>>> dbus-:1.1-org.fedoraproject.Setroubleshootd@15.service:
>>>>> Succeeded.
>>>>>
>>>>> So it looks like now I am told to run:
>>>>>
>>>>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
>>>>> semodule -X 300 -i my-mycron.pp
>>>>>
>>>>> Wait, that is the same I ran earlier? And why did I have to grep
>>>>> messages to find these?
>>>>>
>>>> Hi,
>>>>
>>>> Could you please share output of this command:
>>>>
>>>> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>>> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>>> Error
>>> query_alerts error (1003): id (8eb93a73-c7ff-42ec-bee1-594d77540808) not
>>> found
>>>
>>> And from the first selinux alert:
>>>
>>> # sealert -l d05d8373-fae7-447e-b45a-74940959809e
>>> Error
>>> query_alerts error (1003): id (d05d8373-fae7-447e-b45a-74940959809e) not
>>> found
>>>
>>> I viewed the alerts with the SELinux troubleshooter, but I did NOT tell
>>> it to delete the alert :(
>>>
>> No problem, are you able to reproduce it? If yes, please do and then
>> attach:
>>
>> # ausearch -m AVC,USER_AVC -ts today
> # ausearch -m AVC,USER_AVC -ts today
> ----
> time->Tue May 12 03:22:06 2020
> type=AVC msg=audit(1589268126.630:3796): avc: denied { add_name } for
> pid=142359 comm="mycron" name="root"
> scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0
>
> May 12 03:22:06 lx140e audit[142359]: AVC avc: denied { add_name }
> for pid=142359 comm="mycron" name="root"
> scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0
> May 12 03:22:09 lx140e systemd[1]: Started
> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service.
> May 12 03:22:09 lx140e audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20
comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
> May 12 03:22:13 lx140e systemd[1]: Started
> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service.
> May 12 03:22:13 lx140e audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10
> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> terminal=? res=success'
> May 12 03:22:19 lx140e setroubleshoot[142374]: SELinux is preventing
> mycron from add_name access on the directory root. For complete SELinux
> messages run: sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
> May 12 03:22:19 lx140e python3[142374]: SELinux is preventing mycron
> from add_name access on the directory root.#012#012***** Plugin
> catchall (100. confidence) suggests **************************#012#012If
> you believe that mycron should be allowed add_name access on the root
> directory by default.#012Then you should report this as a bug.#012You
> can generate a local policy module to allow this access.#012Do#012allow
> this access for now by executing:#012# ausearch -c 'mycron' --raw |
> audit2allow -M my-mycron#012# semodule -X 300 -i my-mycron.pp#012
> May 12 03:22:23 lx140e systemd[1]:
> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service: Succeeded.
> May 12 03:22:23 lx140e audit[1]: SERVICE_STOP pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20
comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
> May 12 03:22:23 lx140e systemd[1]:
> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service: Consumed 3.306s
> CPU time.
> May 12 03:22:25 lx140e systemd[1]:
> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service: Succeeded.
> May 12 03:22:25 lx140e audit[1]: SERVICE_STOP pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10
> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> terminal=? res=success'
> May 12 03:22:25 lx140e systemd[1]:
> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service:
> Consumed 5.271s CPU time.
>
> # sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
> Error
> query_alerts error (1003): id (9fd5890f-400b-4ae0-8a98-43575ac4913a) not
> found
>
>
Can you attach your "mycron" script? THere is some issue with SELinux
domain transition.
Oh, and this script runs fine for root's crontab tasks. It is failing
on whatever kicks off logwatch.
11:13 a.m.
New subject: permission problems with script run via crondargs -m
On 5/12/20 5:50 PM, Robert Moskowitz wrote:
--
Lukas Vrabec
SELinux Evangelist,
Senior Software Engineer, Security Technologies
Red Hat, Inc.
On 5/12/20 11:36 AM, Lukas Vrabec wrote:
> On 5/12/20 1:31 PM, Robert Moskowitz wrote:
>> Lukas,
>>
>> Failed again last night see the end of this message.
>>
>> On 5/11/20 9:40 AM, Lukas Vrabec wrote:
>>> On 5/11/20 3:19 PM, Robert Moskowitz wrote:
>>>> On 5/11/20 9:04 AM, Lukas Vrabec wrote:
>>>>> On 5/11/20 2:23 PM, Robert Moskowitz wrote:
>>>>>> A little background first.
>>>>>>
>>>>>> This is for Fedora 32 workstation which does not come with a
>>>>>> default MTA
>>>>>> and thus there is a slight challenge (ahem) getting CRON's
output
>>>>>> into
>>>>>> the local mailstore. I don't want to install an MTA (leave
why for
>>>>>> Fedora users list discuss) and "procmail -f cron"
leaves out a DATE
>>>>>> header. So I wrote my own little script that I put in
>>>>>> /usr/local/mycron
>>>>>> that takes the output from cron and appends the proper content
to
>>>>>> /var/spool/mail/$USER.
>>>>>>
>>>>>> Works fine for my personal crontab, but has selinux problems for
>>>>>> logwatch running as root (and probably any other cron task
>>>>>> running as
>>>>>> root).
>>>>>>
>>>>>> So I first got told by selinux troubleshooting that I needed:
>>>>>>
>>>>>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
>>>>>> semodule -X 300 -i my-mycron.pp
>>>>>>
>>>>>> Which I did. Then after this night's run of logwatch, I see
that I
>>>>>> have
>>>>>> the selinux troubleshoot icon, but when I look, it is empty? So
I
>>>>>> grep
>>>>>> messages for logwatch, then grep the time it was running and
>>>>>> found the
>>>>>> following:
>>>>>>
>>>>>> May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is
preventing
>>>>>> mycron from add_name
>>>>>> access on the directory root. For complete SELinux messages run:
>>>>>> sealert
>>>>>> -l 8eb93a73-c7ff-
>>>>>> 42ec-bee1-594d77540808
>>>>>> May 11 03:43:19 lx140e python3[121345]: SELinux is preventing
mycron
>>>>>> from add_name access
>>>>>> on the directory root.#012#012***** Plugin catchall (100.
>>>>>> confidence)
>>>>>> suggests ********
>>>>>> ******************#012#012If you believe that mycron should be
>>>>>> allowed
>>>>>> add_name access on
>>>>>> the root directory by default.#012Then you should report this as
a
>>>>>> bug.#012You can generat
>>>>>> e a local policy module to allow this access.#012Do#012allow
this
>>>>>> access
>>>>>> for now by execut
>>>>>> ing:#012# ausearch -c 'mycron' --raw | audit2allow -M
my-mycron#012#
>>>>>> semodule -X 300 -i my
>>>>>> -mycron.pp#012
>>>>>> May 11 03:43:23 lx140e systemd[1]:
>>>>>> dbus-:1.1-org.fedoraproject.Setroubleshootd@15.service:
>>>>>> Succeeded.
>>>>>>
>>>>>> So it looks like now I am told to run:
>>>>>>
>>>>>> ausearch -c 'mycron' --raw | audit2allow -M my-mycron
>>>>>> semodule -X 300 -i my-mycron.pp
>>>>>>
>>>>>> Wait, that is the same I ran earlier? And why did I have to
grep
>>>>>> messages to find these?
>>>>>>
>>>>> Hi,
>>>>>
>>>>> Could you please share output of this command:
>>>>>
>>>>> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>>>> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>>>> Error
>>>> query_alerts error (1003): id
>>>> (8eb93a73-c7ff-42ec-bee1-594d77540808) not
>>>> found
>>>>
>>>> And from the first selinux alert:
>>>>
>>>> # sealert -l d05d8373-fae7-447e-b45a-74940959809e
>>>> Error
>>>> query_alerts error (1003): id
>>>> (d05d8373-fae7-447e-b45a-74940959809e) not
>>>> found
>>>>
>>>> I viewed the alerts with the SELinux troubleshooter, but I did NOT
>>>> tell
>>>> it to delete the alert :(
>>>>
>>> No problem, are you able to reproduce it? If yes, please do and then
>>> attach:
>>>
>>> # ausearch -m AVC,USER_AVC -ts today
>> # ausearch -m AVC,USER_AVC -ts today
>> ----
>> time->Tue May 12 03:22:06 2020
>> type=AVC msg=audit(1589268126.630:3796): avc: denied { add_name } for
>> pid=142359 comm="mycron" name="root"
>> scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0
>>
>> May 12 03:22:06 lx140e audit[142359]: AVC avc: denied { add_name }
>> for pid=142359 comm="mycron" name="root"
>> scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023
>> tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0
>> May 12 03:22:09 lx140e systemd[1]: Started
>> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service.
>> May 12 03:22:09 lx140e audit[1]: SERVICE_START pid=1 uid=0
>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>> msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20
comm="systemd"
>> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
>> May 12 03:22:13 lx140e systemd[1]: Started
>> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service.
>> May 12 03:22:13 lx140e audit[1]: SERVICE_START pid=1 uid=0
>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>> msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10
>> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=?
addr=?
>> terminal=? res=success'
>> May 12 03:22:19 lx140e setroubleshoot[142374]: SELinux is preventing
>> mycron from add_name access on the directory root. For complete SELinux
>> messages run: sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
>> May 12 03:22:19 lx140e python3[142374]: SELinux is preventing mycron
>> from add_name access on the directory root.#012#012***** Plugin
>> catchall (100. confidence) suggests **************************#012#012If
>> you believe that mycron should be allowed add_name access on the root
>> directory by default.#012Then you should report this as a bug.#012You
>> can generate a local policy module to allow this access.#012Do#012allow
>> this access for now by executing:#012# ausearch -c 'mycron' --raw |
>> audit2allow -M my-mycron#012# semodule -X 300 -i my-mycron.pp#012
>> May 12 03:22:23 lx140e systemd[1]:
>> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service: Succeeded.
>> May 12 03:22:23 lx140e audit[1]: SERVICE_STOP pid=1 uid=0
>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>> msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20
comm="systemd"
>> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
>> May 12 03:22:23 lx140e systemd[1]:
>> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service: Consumed 3.306s
>> CPU time.
>> May 12 03:22:25 lx140e systemd[1]:
>> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service:
>> Succeeded.
>> May 12 03:22:25 lx140e audit[1]: SERVICE_STOP pid=1 uid=0
>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>> msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10
>> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=?
addr=?
>> terminal=? res=success'
>> May 12 03:22:25 lx140e systemd[1]:
>> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service:
>> Consumed 5.271s CPU time.
>>
>> # sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
>> Error
>> query_alerts error (1003): id (9fd5890f-400b-4ae0-8a98-43575ac4913a) not
>> found
>>
>>
> Can you attach your "mycron" script? THere is some issue with SELinux
> domain transition.
Oh, and this script runs fine for root's crontab tasks. It is failing
on whatever kicks off logwatch.
Yes, that's the problem.
Can you please run:
# semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
# restorecon -Rv /usr/local
and then reproduce it? This could help.
Thanks,
Lukas.
11:51 a.m.
New subject: permission problems with script run via crondargs -m
On 5/12/20 12:13 PM, Lukas Vrabec wrote:
On 5/12/20 5:50 PM, Robert Moskowitz wrote:
>
> On 5/12/20 11:36 AM, Lukas Vrabec wrote:
>> On 5/12/20 1:31 PM, Robert Moskowitz wrote:
>>> Lukas,
>>>
>>> Failed again last night see the end of this message.
>>>
>>> On 5/11/20 9:40 AM, Lukas Vrabec wrote:
>>>> On 5/11/20 3:19 PM, Robert Moskowitz wrote:
>>>>> On 5/11/20 9:04 AM, Lukas Vrabec wrote:
>>>>>> On 5/11/20 2:23 PM, Robert Moskowitz wrote:
>>>>>>> A little background first.
>>>>>>>
>>>>>>> This is for Fedora 32 workstation which does not come with a
>>>>>>> default MTA
>>>>>>> and thus there is a slight challenge (ahem) getting
CRON's output
>>>>>>> into
>>>>>>> the local mailstore. I don't want to install an MTA
(leave why for
>>>>>>> Fedora users list discuss) and "procmail -f cron"
leaves out a DATE
>>>>>>> header. So I wrote my own little script that I put in
>>>>>>> /usr/local/mycron
>>>>>>> that takes the output from cron and appends the proper
content to
>>>>>>> /var/spool/mail/$USER.
>>>>>>>
>>>>>>> Works fine for my personal crontab, but has selinux problems
for
>>>>>>> logwatch running as root (and probably any other cron task
>>>>>>> running as
>>>>>>> root).
>>>>>>>
>>>>>>> So I first got told by selinux troubleshooting that I
needed:
>>>>>>>
>>>>>>> ausearch -c 'mycron' --raw | audit2allow -M
my-mycron
>>>>>>> semodule -X 300 -i my-mycron.pp
>>>>>>>
>>>>>>> Which I did. Then after this night's run of logwatch, I
see that I
>>>>>>> have
>>>>>>> the selinux troubleshoot icon, but when I look, it is empty?
So I
>>>>>>> grep
>>>>>>> messages for logwatch, then grep the time it was running and
>>>>>>> found the
>>>>>>> following:
>>>>>>>
>>>>>>> May 11 03:43:19 lx140e setroubleshoot[121345]: SELinux is
preventing
>>>>>>> mycron from add_name
>>>>>>> access on the directory root. For complete SELinux messages
run:
>>>>>>> sealert
>>>>>>> -l 8eb93a73-c7ff-
>>>>>>> 42ec-bee1-594d77540808
>>>>>>> May 11 03:43:19 lx140e python3[121345]: SELinux is preventing
mycron
>>>>>>> from add_name access
>>>>>>> on the directory root.#012#012***** Plugin catchall (100.
>>>>>>> confidence)
>>>>>>> suggests ********
>>>>>>> ******************#012#012If you believe that mycron should
be
>>>>>>> allowed
>>>>>>> add_name access on
>>>>>>> the root directory by default.#012Then you should report this
as a
>>>>>>> bug.#012You can generat
>>>>>>> e a local policy module to allow this access.#012Do#012allow
this
>>>>>>> access
>>>>>>> for now by execut
>>>>>>> ing:#012# ausearch -c 'mycron' --raw | audit2allow -M
my-mycron#012#
>>>>>>> semodule -X 300 -i my
>>>>>>> -mycron.pp#012
>>>>>>> May 11 03:43:23 lx140e systemd[1]:
>>>>>>> dbus-:1.1-org.fedoraproject.Setroubleshootd@15.service:
>>>>>>> Succeeded.
>>>>>>>
>>>>>>> So it looks like now I am told to run:
>>>>>>>
>>>>>>> ausearch -c 'mycron' --raw | audit2allow -M
my-mycron
>>>>>>> semodule -X 300 -i my-mycron.pp
>>>>>>>
>>>>>>> Wait, that is the same I ran earlier? And why did I have to
grep
>>>>>>> messages to find these?
>>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Could you please share output of this command:
>>>>>>
>>>>>> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>>>>> # sealert -l 8eb93a73-c7ff-42ec-bee1-594d77540808
>>>>> Error
>>>>> query_alerts error (1003): id
>>>>> (8eb93a73-c7ff-42ec-bee1-594d77540808) not
>>>>> found
>>>>>
>>>>> And from the first selinux alert:
>>>>>
>>>>> # sealert -l d05d8373-fae7-447e-b45a-74940959809e
>>>>> Error
>>>>> query_alerts error (1003): id
>>>>> (d05d8373-fae7-447e-b45a-74940959809e) not
>>>>> found
>>>>>
>>>>> I viewed the alerts with the SELinux troubleshooter, but I did NOT
>>>>> tell
>>>>> it to delete the alert :(
>>>>>
>>>> No problem, are you able to reproduce it? If yes, please do and then
>>>> attach:
>>>>
>>>> # ausearch -m AVC,USER_AVC -ts today
>>> # ausearch -m AVC,USER_AVC -ts today
>>> ----
>>> time->Tue May 12 03:22:06 2020
>>> type=AVC msg=audit(1589268126.630:3796): avc: denied { add_name } for
>>> pid=142359 comm="mycron" name="root"
>>> scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023
>>> tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0
>>>
>>> May 12 03:22:06 lx140e audit[142359]: AVC avc: denied { add_name }
>>> for pid=142359 comm="mycron" name="root"
>>> scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023
>>> tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir permissive=0
>>> May 12 03:22:09 lx140e systemd[1]: Started
>>> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service.
>>> May 12 03:22:09 lx140e audit[1]: SERVICE_START pid=1 uid=0
>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>> msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20
comm="systemd"
>>> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
>>> May 12 03:22:13 lx140e systemd[1]: Started
>>> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service.
>>> May 12 03:22:13 lx140e audit[1]: SERVICE_START pid=1 uid=0
>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>> msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10
>>> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=?
addr=?
>>> terminal=? res=success'
>>> May 12 03:22:19 lx140e setroubleshoot[142374]: SELinux is preventing
>>> mycron from add_name access on the directory root. For complete SELinux
>>> messages run: sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
>>> May 12 03:22:19 lx140e python3[142374]: SELinux is preventing mycron
>>> from add_name access on the directory root.#012#012***** Plugin
>>> catchall (100. confidence) suggests **************************#012#012If
>>> you believe that mycron should be allowed add_name access on the root
>>> directory by default.#012Then you should report this as a bug.#012You
>>> can generate a local policy module to allow this access.#012Do#012allow
>>> this access for now by executing:#012# ausearch -c 'mycron' --raw |
>>> audit2allow -M my-mycron#012# semodule -X 300 -i my-mycron.pp#012
>>> May 12 03:22:23 lx140e systemd[1]:
>>> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service: Succeeded.
>>> May 12 03:22:23 lx140e audit[1]: SERVICE_STOP pid=1 uid=0
>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>> msg='unit=dbus-:1.1-org.fedoraproject.Setroubleshootd@20
comm="systemd"
>>> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
>>> May 12 03:22:23 lx140e systemd[1]:
>>> dbus-:1.1-org.fedoraproject.Setroubleshootd@20.service: Consumed 3.306s
>>> CPU time.
>>> May 12 03:22:25 lx140e systemd[1]:
>>> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service:
>>> Succeeded.
>>> May 12 03:22:25 lx140e audit[1]: SERVICE_STOP pid=1 uid=0
>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>> msg='unit=dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10
>>> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=?
addr=?
>>> terminal=? res=success'
>>> May 12 03:22:25 lx140e systemd[1]:
>>> dbus-:1.1-org.fedoraproject.SetroubleshootPrivileged@10.service:
>>> Consumed 5.271s CPU time.
>>>
>>> # sealert -l 9fd5890f-400b-4ae0-8a98-43575ac4913a
>>> Error
>>> query_alerts error (1003): id (9fd5890f-400b-4ae0-8a98-43575ac4913a) not
>>> found
>>>
>>>
>> Can you attach your "mycron" script? THere is some issue with SELinux
>> domain transition.
> Oh, and this script runs fine for root's crontab tasks. It is failing
> on whatever kicks off logwatch.
>
Yes, that's the problem.
Can you please run:
# semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
# restorecon -Rv /usr/local
and then reproduce it? This could help.
restorecon -Rv /usr/local
Relabeled /usr/local/mycron from unconfined_u:object_r:usr_t:s0 to
unconfined_u:object_r:sendmail_exec_t:s0
Interesting...
Now we will see what happens tonight.
5 p.m.
New subject: permission problems with script run via crondargs -m
On 2020-05-13 00:51, Robert Moskowitz wrote:
restorecon -Rv /usr/local
Relabeled /usr/local/mycron from unconfined_u:object_r:usr_t:s0 to
unconfined_u:object_r:sendmail_exec_t:s0
Interesting...
Now we will see what happens tonight.
You may want to consider trimming replies at some point so as not to have to overuse the
the scroll
button?
--
The key to getting good answers is to ask good questions.
8:26 a.m.
New subject: permission problems with script run via crondargs -m
On 5/12/20 12:13 PM, Lukas Vrabec wrote:
Oh, and this script runs fine for root's crontab tasks. It is
failing
> on whatever kicks off logwatch.
>
Yes, that's the problem.
Can you please run:
# semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
# restorecon -Rv /usr/local
and then reproduce it? This could help.
It works now. Thanks!
Of course I am changing my mycron script yet again! I was shown how to
use formail/procmail as a simple MDA. Still need a script file, and
probably still need all these selinux changes for it,
eventhough only procmail is touching /var/spool/mail/
8:36 a.m.
New subject: permission problems with script run via crondargs -m
On 5/13/20 3:26 PM, Robert Moskowitz wrote:
On 5/12/20 12:13 PM, Lukas Vrabec wrote:
> Oh, and this script runs fine for root's crontab tasks. It is failing
>> on whatever kicks off logwatch.
>>
> Yes, that's the problem.
>
>
> Can you please run:
>
> # semanage fcontext -a -t sendmail_exec_t /usr/local/mycron
> # restorecon -Rv /usr/local
>
> and then reproduce it? This could help.
It works now. Thanks!
Great to hear that!
Of course I am changing my mycron script yet again! I was shown how
to
use formail/procmail as a simple MDA. Still need a script file, and
probably still need all these selinux changes for it,
eventhough only procmail is touching /var/spool/mail/
--
Lukas Vrabec
SELinux Evangelist,
Senior Software Engineer, Security Technologies
Red Hat, Inc.
1506
days inactive
1507
days old
selinux@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Ed Greshko -
Lukas Vrabec -
Robert Moskowitz