lnk_file read permission
by Gionatan Danti
Hi all,
using selinux, I saw many times that when relocating service dirs (eg:
mysql, mongodb, etc) putting a symlink in the original location, the
affected services fail to start due to missing lnk_file read permission.
As selinux works with target file label and it is path-agnostic (this
is, indeed, a major selinux feature), while is the lnk_file read often
not granted by default? Does granting it expose to additional attack
vectors?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
3 years, 10 months
new service blocked by selinux
by Rod Davison
I am running fedora32. I am trying to start a program as a service and run
it with a non-root user id (radmin).
I have created /home/radmin/bin/jungledisk.sh (which has permission ug=rwx)
I have create /etc/systemd/system/jungledisk.service
When I start the service with "sudo systemctl restart jungledisk.service" I
get error messages -- see below.
I have attempted to follow the instructions to create a local policy from
the log file by executing:
sudo ausearch -c '(edisk.sh)' --raw | sudo audit2allow -M my-edisksh
sudo semodule -X 300 -i my-edisksh.pp
however, the behaviour is the same after running this.
The jungledisk.service files is attempting to run jungledisk.sh as user
radmin, if that's relevant.
Advise appreciated.
the following in my /var/log/messages file:
May 23 17:53:32 localhost systemd[613445]: jungledisk.service: Failed to
execute command: Permission denied
May 23 17:53:32 localhost systemd[613445]: jungledisk.service: Failed at
step EXEC spawning /home/radmin/bin/jungledisk.sh: Permission denied
...
May 23 17:53:34 localhost setroubleshoot[613447]: SELinux is preventing
(edisk.sh) from execute_no_trans access on the file
/home/radmin/bin/jungledisk.sh. For complete SELinux messages run: sealert
-l 0b9955ca-66c6-4039-9999-2dd7d4ec0fc8
May 23 17:53:34 localhost python3[613447]: SELinux is preventing (edisk.sh)
from execute_no_trans access on the file
/home/radmin/bin/jungledisk.sh.#012#012***** Plugin catchall (100.
confidence) suggests **************************#012#012If you believe
that (edisk.sh) should be allowed execute_no_trans access on the
jungledisk.sh file 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
'(edisk.sh)' --raw | audit2allow -M my-edisksh#012# semodule -X 300 -i
my-edisksh.pp#012
May 23 17:53:34 localhost dbus-broker-launch[281848]: avc: received
policyload notice (seqno=3)
May 23 17:53:34 localhost dbus-broker-launch[281848]: avc: received
policyload notice (seqno=4)
May 23 17:53:34 localhost systemd[11047]: selinux: avc: received
policyload notice (seqno=3)
May 23 17:53:34 localhost systemd[11047]: selinux: avc: received
policyload notice (seqno=4)
May 23 17:53:34 localhost systemd[11047]: Started
dbus-:1.1-org.freedesktop.Notifications@14.service.
May 23 17:53:34 localhost at-spi-bus-launcher[294822]: avc: received
policyload notice (seqno=3)
May 23 17:53:34 localhost at-spi-bus-launcher[294822]: avc: received
policyload notice (seqno=4)
May 23 17:53:37 localhost setroubleshoot[613447]: SELinux is preventing
(edisk.sh) from execute_no_trans access on the file
/home/radmin/bin/jungledisk.sh. For complete SELinux messages run: sealert
-l 0b9955ca-66c6-4039-9999-2dd7d4ec0fc8
May 23 17:53:37 localhost python3[613447]: SELinux is preventing (edisk.sh)
from execute_no_trans access on the file
/home/radmin/bin/jungledisk.sh.#012#012***** Plugin catchall (100.
confidence) suggests **************************#012#012If you believe
that (edisk.sh) should be allowed execute_no_trans access on the
jungledisk.sh file 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
'(edisk.sh)' --raw | audit2allow -M my-edisksh#012# semodule -X 300 -i
my-edisksh.pp#012
4 years
Updating security classes and access vectors in Fedora policy?
by Stephen Smalley
Hi,
Fedora policy has a number of differences in its security_classes and
access_vectors from current refpolicy, and neither are fully up to date
with the kernel (but refpolicy is closer). One consequence of this is
that parts of the selinux-testsuite do not run by default on Fedora
(including rawhide) at present and still require manual patching by
testers if they want to exercise all the tests.
Differences that I see include:
- refpolicy has added the watch* permissions exercised by the
selinux-testsuite/tests/{notify,filesystem,fs_filesystem} tests. These
were first defined in refpolicy by
https://github.com/SELinuxProject/refpolicy/commit/c656b97a289ce6c2da2871...
but there have been a series of subsequent commits (one to fix an
ordering problem to better align with the kernel) and then allowing
these new watch permissions as needed.
- refpolicy has added the perf_event class exercised by the
selinux-testsuite/tests/perf_event tests. These were first defined in
refpolicy by
https://github.com/SELinuxProject/refpolicy/commit/624a63704c19a653486f37....
- Neither refpolicy nor fedora have yet added the lockdown class
exercised by selinux-testsuite/tests/lockdown. The kernel commit
introducing this class is
https://github.com/SELinuxProject/selinux-kernel/commit/59438b46471ae6cdf....
Other differences that don't directly affect the testsuite execution:
- Drop unused socket security classes,
https://github.com/SELinuxProject/refpolicy/commit/4637cd6f898e95ffa95b2d...
- Remove unused permissions,
https://github.com/SELinuxProject/refpolicy/commit/161bda392e61056ea22fe9...
- Remove entrypoint and execute_no_trans from chr_file,
https://github.com/SELinuxProject/refpolicy/commit/8486b8aa83afa7abd94c93...
- remove flow_in and flow_out permissions from packet class,
https://github.com/SELinuxProject/refpolicy/commit/f4459adf3242ed2dbc35e2...
- Rename obsolete netlink_firewall_socket and netlink_ip6fw_socket
classes,
https://github.com/SELinuxProject/refpolicy/commit/5fd175fa453e995d8b7357...
- Remove unused translate permission in context userspace class,
https://github.com/SELinuxProject/refpolicy/commit/65da822c1b5c70bd1ff7ec...
- Fedora policy has an "undefined" permission in its class system access
vector, not present in refpolicy (some kind of compatibility hack?).
- Fedora policy has an "epolwakeup" permission in its class capability2
access vector, not present in refpolicy (old name for block_suspend,
never included in an official kernel release, also not even correct
originally - should have been epollwakeup).
- Fedora policy has "getnetgrp" and "shmemnetgrp" permissions in its
class nscd access vector, not sure if those are used by glibc/ncsd code
but if so should get added to refpolicy too.
- Fedora policy has a "proxy" class and access vector for "gssd", not
present in refpolicy. If that's something that isn't Fedora-specific,
it should probably get upstreamed to refpolicy although the class name
isn't very descriptive.
- refpolicy has "db_exception" and "db_datatype" classes and access
vectors for "Interbase/Firebird/Red Database", not present in Fedora.
Don't know if that matters to Fedora.
- Various whitespace/comment cleanups in refpolicy not in Fedora.
- process2 is declared at a different place in security_classes in
refpolicy versus Fedora. Doesn't really matter since kernel uses
dynamic class/perm support and no fixed definition ever defined in
libselinux/libsepol headers but might be good to align them for consistency.
NB The removals and renames may have some compatibility implications,
e.g. a local or third party policy module built against the existing
Fedora policy headers may have picked up dependencies on these
classes/permissions and therefore may need to be rebuilt against the
updated headers in order to still link successfully. This could break
upon an update if those local or third party modules were installed at
the time of the update since we'd fail on the semodule -B during %post,
leaving the system with the old policy. rpm selinux support was
supposed to fix that kind of thing by handling it via plugin and not
from %post and rolling the package update back but never got adopted/used ;(
4 years, 1 month
Issues with the include/contrib/courier.if policy
by Sam Varshavchik
Fedora's selinux package has a contributed policy for Courier,
include/contrib/courier.if, which has two issues (that I found so far) with
my upstream rpm packages. My rpm packages have worked this way for a long
time, probably 15+ years, or so, this is not a recent change. The only thing
that changed is that I'm actually tried to run in enforcing mode late last
year, and ran into this. I'm picking this issue up now, for one last college
try to figure out the fix.
I couldn't figure out how courier.if works; so last time after doing some
random reading, I was able to come up with a band-aid for the first issue.
The rpm package installs a binary in /var/www/cgi-bin that talks to the
running webmail daemon over an AF_Unix socket. selinux's policy was labeling
the /var/www/cgi-bin binary, and blocking its socket connection. The band-
aid was this additional local policy:
policy_module(courier_webmail, 1.0)
require {
type httpd_sys_script_t;
type courier_spool_t;
};
allow httpd_sys_script_t courier_spool_t:dir search_dir_perms;
allow httpd_sys_script_t courier_spool_t:sock_file manage_sock_file_perms;
That seemed innocent enough. But I revisited the entire package this week,
and found two more issues.
The first one is an additional AVC that was now blocking the same webmail
binary:
type=AVC msg=audit(1589086763.118:1319): avc: denied { connectto } for
pid=674413 comm="webmail" path="/var/spool/courier/sqwebmail.sock"
scontext=system_u:system_r:httpd_sys_script_t:s0
tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket
permissive=0
This was new, I could not figure out why the target context was unconfined,
because:
[root@jack ~]# ls -alZ /var/spool/courier/sqwebmail.sock
srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 10 01:15
/var/spool/courier/sqwebmail.sock
As a band-aid on top of the first band-aid, I added
allow httpd_sys_script_t unconfined_service_t:unix_stream_socket connectto;
to the local policy, to get it working. But this doesn't seem ideal.
The second issue was that an individual uninstall of one of the rpm-
subpackages was hanging. selinux was blocking a signal sent by binary that
%preun runs. The signal is sent to the running process:
type=AVC msg=audit(1589082060.526:1156): avc: denied { signal } for
pid=672912 comm="courierlogger"
scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023
tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process
permissive=0
and
type=AVC msg=audit(1589082160.527:1172): avc: denied { sigkill } for
pid=672912 comm="courierlogger"
scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023
tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process
permissive=0
The main rpm package's systemd unit runs a startup script that inventories
which subpackages are installed, and starts each one's service. Manually
uninstalling an rpm subpackage executes a %preun that stops just its own
service, and this part is getting blocked. The binary that sends the signal
appears to be labeled by the contributed Fedora policy:
rwxr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 25296 May 9
23:19 /usr/sbin/courierlogger
The binary is trying to send a signal to one of these processes:
system_u:system_r:unconfined_service_t:s0 root 780748 780747 0 01:15 ?
00:00:00 /usr/lib/courier/sbin/couriertcpd [parameters]
r-xr-xr-x. 1 daemon daemon system_u:object_r:bin_t:s0 142456 May 10 01:14
/usr/lib/courier/sbin/couriertcpd
I could avoid this by systemctl stop in %preun and systemctl start in
%postun, I suppose. Startup and shutdown, which sends the same signal via
the same binary, seems to work when the main rpm package runs systemctl
stop. But doing it this way stops and restarts everything when a single
subpackage gets removed, this is not ideal.
4 years, 1 month
Re: permission problems with script run via crondargs -m
by Robert Moskowitz
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.
4 years, 1 month
Re: permission problems with script run via crondargs -m
by Robert Moskowitz
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.
I just made a few improvements to it, but here is what ran last night:
local]# cat mycron
#!/bin/sh
# the sed commands only work if USER == MAILTO in crontab
exec 3>> /var/spool/mail/$USER
exec 100>/var/tmp/$USERlock.lock || exit 1
flock -w 120 100 || exit 1
currentDate=$(date +'%a %b %d %T %Y')
echo "From cron@localhost $currentDate" >&3
currentDate2=$(date +'%a, %e %b %Y %T %z (%Z)')
echo "Date: $currentDate2" >&3
echo "Message-ID: $(uuidgen)@$HOSTNAME" >&3
# (cat) >&3
(sed -e "/^From: / s/$USER/$USER@$HOSTNAME/"|sed -e "/^To: /
s/$USER/$USER@$HOSTNAME/") >&3
echo "" >&3
The flock stuff was added yesterday, and was not in the previous failures.
4 years, 1 month
permission problems with script run via crondargs -m
by Robert Moskowitz
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?
Now I did update mycron in between. Will I have to run this every time
I update mycron? How do I make it permanent? Also right now there is
no /var/spool/mail/root mbox file.
thanks
4 years, 1 month
openarc package needs a selinux module
by Matt Domsch
The openarc package provides a milter implementing the Authenticated
Receive Chain (ARC) email signing and verification method as described in
RFC 8617. See also http://arc-spec.org/.
This software is very similar in behavior as that of OpenDKIM, in that:
- it can open and listen on a tcp or a unix socket in /run/openarc to
which an MTA connects (e.g. sendmail or postfix)
- it must make outgoing DNS requests to look up keys in DNS TXT records.
When run without a policy, it fails with sendmail unable to connect to
sockets of type var_run_t in /etc/openarc/openarc.sock.
At a minimum, we need to label /etc/openarc/* in a way that postfix and
sendmail can connect. We've experimented with reusing dkim_milter_data_t ,
which does work:
/var/run/openarc(/.*)?
gen_context(system_u:object_r:dkim_milter_data_t,s0)
/var/spool/postfix/var/run/openarc(/.*)?
gen_context(system_u:object_r:dkim_milter_data_t,s0)
In addition, I note that the dkim-milter (not the opendkim package) also
has a file context to protect it's private keys.
/etc/mail/dkim-milter/keys(/.*)? all files
system_u:object_r:dkim_milter_private_key_t:s0
and runs in a context of dkim_milter_exec_t rather than unconfined_t.
This is being discussed in github PR contents upstream.
https://github.com/trusteddomainproject/OpenARC/pull/103
What's the best way to proceed?
Thanks,
Matt
4 years, 1 month
