Bug 2029039 - selinux warning on ntfs3 driver
Summary: selinux warning on ntfs3 driver
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-12-04 10:05 UTC by Syaifur Rizal
Modified: 2022-02-17 03:15 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-35.15-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-15 09:29:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
ausearch result (25.68 KB, text/plain)
2021-12-06 09:50 UTC, Syaifur Rizal
no flags Details

Description Syaifur Rizal 2021-12-04 10:05:24 UTC
Description of problem:

When uninstalling ntfs-3g and relying only on ntfs driver from kernel (5.15 and newer), selinux give warning on mounting filesystem.


Version-Release number of selected component (if applicable):

note: I'm not sure where the configuration come but here some version related to currently installed selinux:

selinux-policy.noarch           35.6-1.fc36
libselinux.x86_64               3.3-2.fc36

How reproducible:

Steps to Reproduce:
1. Make sure on kernel 5.15 or 5.16
2. Remove ntfs-3g driver
3. Add auto mount ntfs drive on fstab using: UUID=NTFSUUID	/mnt/target	ntfs3	defaults 0 0
4. Reboot

Actual results:

Warning on Selinux browser. There are two warning:
1. SELinux is preventing (qbalance) from remount access on the filesystem
2. SELinux is preventing (chronyd) from remount access on the filesystem

Expected results:

I believe since it's official that new ntfs driver already merge to the kernel upstream, there should be a default whitelist for this driver.

Additional info:

Comment 1 Milos Malik 2021-12-06 08:11:30 UTC
The information you provided is not sufficient for developing the SELinux policy fix.

Please collect SELinux denials which appeared on your machine:

# ausearch -m avc -m user_avc -m selinux_err -i -ts today

and attach them here. Thank you.

Comment 2 Syaifur Rizal 2021-12-06 09:50:56 UTC
Created attachment 1844874 [details]
ausearch result

Hi, thank you for the response. Here the ausearch result.

Comment 3 Ben Cotton 2022-02-08 21:22:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 4 Tomas Dolezal 2022-02-11 00:35:03 UTC
occuring also on F35 during bootup. not on manual `mount` invocation as root. attempted both on enforcing and permissive boot (kernel cmdline enforcing=0). ntfs-3g package present but unused due to chosen fstype. Mounting always succeeds.

selinux-policy-35.13-1.fc35.noarch
kernel-5.16.8-200.fc35.x86_64

fstab entry:
LABEL=DATA2 /mnt/DATA2 ntfs3 ro,dmask=0007,fmask=0117,gid=wheel,nofail,user 0 0

# LANG=C mount -v /mnt/DATA2/
mount: /mnt/DATA2 does not contain SELinux labels.
       You just mounted a file system that supports labels which does not
       contain labels, onto an SELinux box. It is likely that confined
       applications will generate AVC messages and not be allowed access to
       this file system.  For more details see restorecon(8) and mount(8).
mount: /dev/sdb1 mounted on /mnt/DATA2.

# stat -c %C\ %n /mnt/DATA2/
system_u:object_r:unlabeled_t:s0 /mnt/DATA2/

# ausearch -m avc -m user_avc -m selinux_err -i -ts today
----
type=AVC msg=audit(02/11/2022 00:33:13.478:792) : avc:  denied  { remount } for  pid=36011 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=0 
----
type=AVC msg=audit(02/11/2022 00:33:13.478:793) : avc:  denied  { remount } for  pid=36011 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=0 
----
type=AVC msg=audit(02/11/2022 00:33:13.478:794) : avc:  denied  { remount } for  pid=36011 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=0 
----
type=AVC msg=audit(02/11/2022 00:33:13.478:795) : avc:  denied  { remount } for  pid=36011 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=0 
----
type=AVC msg=audit(02/11/2022 00:33:13.478:796) : avc:  denied  { remount } for  pid=36011 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=0 
----
type=PROCTITLE msg=audit(02/11/2022 00:39:51.765:161) : proctitle=(resolved) 
type=SYSCALL msg=audit(02/11/2022 00:39:51.765:161) : arch=x86_64 syscall=mount success=yes exit=0 a0=0x0 a1=0x7fff372679a0 a2=0x0 a3=MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_REMOUNT|MS_BIND items=0 ppid=1 pid=2140 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=(resolved) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null) 
type=AVC msg=audit(02/11/2022 00:39:51.765:161) : avc:  denied  { remount } for  pid=2140 comm=(resolved) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 
----
type=AVC msg=audit(02/11/2022 00:39:51.886:177) : avc:  denied  { remount } for  pid=2222 comm=(d-logind) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 
----
type=AVC msg=audit(02/11/2022 00:39:52.015:203) : avc:  denied  { remount } for  pid=2280 comm=(ostnamed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 
----
type=AVC msg=audit(02/11/2022 00:39:52.493:216) : avc:  denied  { remount } for  pid=2409 comm=(vnstatd) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1 
----
type=AVC msg=audit(02/11/2022 00:40:27.641:388) : avc:  denied  { remount } for  pid=6411 comm=(-localed) scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1

Comment 5 Ondrej Mosnacek 2022-02-11 11:15:23 UTC
I think we need to add a new genfscon line into the policy for the new "ntfs3" filesystem. We currently only have rules for "ntfs" and "ntfs-3g".

Can someone check if the following fixes the issue?

$ echo '(genfscon ntfs3 "/" (system_u object_r dosfs_t ((s0) (s0))))' >ntfs3_genfscon.cil
$ sudo semodule -i ntfs3_genfscon.cil

To remove the dummy SELinux module after testing:

$ sudo semodule -r ntfs3_genfscon

Comment 6 Tomas Dolezal 2022-02-11 11:59:55 UTC
(In reply to Ondrej Mosnacek from comment #5)
> Can someone check if the following fixes the issue?
> 
> $ echo '(genfscon ntfs3 "/" (system_u object_r dosfs_t ((s0) (s0))))'
> >ntfs3_genfscon.cil
> $ sudo semodule -i ntfs3_genfscon.cil

This fixed my issue, no more warnings on reboots.

Comment 7 Syaifur Rizal 2022-02-11 12:52:40 UTC
(In reply to Ondrej Mosnacek from comment #5)
> I think we need to add a new genfscon line into the policy for the new
> "ntfs3" filesystem. We currently only have rules for "ntfs" and "ntfs-3g".
> 
> Can someone check if the following fixes the issue?
> 
> $ echo '(genfscon ntfs3 "/" (system_u object_r dosfs_t ((s0) (s0))))'
> >ntfs3_genfscon.cil
> $ sudo semodule -i ntfs3_genfscon.cil
> 
> To remove the dummy SELinux module after testing:
> 
> $ sudo semodule -r ntfs3_genfscon

Great, this also fixed my issue. 👍

Comment 8 Ondrej Mosnacek 2022-02-11 13:11:47 UTC
Thanks, opened a PR to fix it in selinux-policy:
https://github.com/fedora-selinux/selinux-policy/pull/1067

Comment 9 Fedora Update System 2022-02-14 11:21:01 UTC
FEDORA-2022-5bcfd81271 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5bcfd81271

Comment 10 Syaifur Rizal 2022-02-15 09:29:05 UTC
Thank you. I close this bug report.

Comment 11 Fedora Update System 2022-02-15 14:58:14 UTC
FEDORA-2022-aa5df3a7eb has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-aa5df3a7eb

Comment 12 Fedora Update System 2022-02-16 01:50:57 UTC
FEDORA-2022-aa5df3a7eb has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-aa5df3a7eb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-aa5df3a7eb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2022-02-17 03:15:12 UTC
FEDORA-2022-aa5df3a7eb has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.