Ask Your Question
2

SELinux alert caused by VirtualBox after every kernel update

asked 2018-09-22 07:52:31 -0500

tachi gravatar image

updated 2018-10-01 17:21:08 -0500

Actually it is not of a big deal, because VirtualBox works fine, but I want to try to understand these alerts from SELinux. In a nutshelll what I have understood is the following: vboxdrv.sh located in /usr/lib/virtualbox is trying to create a file named vbox-setup.log in /var/log but is prevented by SELinux.

  • I looked up the properties of vboxdrv.sh: -rwxr-xr-x. 1 root root and the security context is system_u:object_r:lib_t:s0
  • vbox-setup.log does not exist, which I think its creation is prevented by SELinux. Am I right?

This is from the SETroubleshoot Details Window

SELinux is preventing vboxdrv.sh from create access on the file vbox-setup.log.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that vboxdrv.sh should be allowed create access on the vbox-setup.log 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:
# ausearch -c 'vboxdrv.sh' --raw | audit2allow -M my-vboxdrvsh
# semodule -X 300 -i my-vboxdrvsh.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:var_log_t:s0
Target Objects                vbox-setup.log [ file ]
Source                        vboxdrv.sh
Source Path                   vboxdrv.sh
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.1-42.fc28.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.18.8-200.fc28.x86_64 #1 SMP Sun Sep
                              16 18:15:41 UTC 2018 x86_64 x86_64
Alert Count                   70
First Seen                    2018-03-20 20:20:00 CET
Last Seen                     2018-09-22 13:54:38 CEST
Local ID                      d57bf0c9-f93e-4b1f-a563-290ec039e7fa

Raw Audit Messages
type=AVC msg=audit(1537617278.521:227): avc:  denied  { create } for  pid=946 comm="vboxdrv.sh" name="vbox-setup.log" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0


Hash: vboxdrv.sh,init_t,var_log_t,file,create
  • Is this a bug?
  • Or is there something wrong?
  • Can someone please explain me what SELinux is trying to tell me?

The following added after kernel update (from 4.18.9-200 to 4.18.10-200) on 1 October: It took some time for the next kernel update. Finally, I executed both commands before updating the kernel. After the update no alert from SELinux. I also cannot find the alerts in SELinux any more.

  • What happened? Are the changes I made with those two lines of commands permanent?

I checked for vbox-setup.log in /var/log and guess what? It is there now with four lines of messages:

Building the main VirtualBox module.
Building the net filter module.
Building the net adaptor module.
Building the PCI pass-through module.

And with file properties -rw-r--r--. 1 root root and security context system_u:object_r:var_log_t:s0 as it should have probably.

edit retag flag offensive close merge delete

Comments

I don't know if it's a bug in the program or in the install scripts, but in either case, you should report it. If it's happening to you, it's probably happening to others but the devs can't correct it until they're told about it.

sideburns gravatar imagesideburns ( 2018-09-22 13:09:16 -0500 )edit
1

You added a new permission rule tp SELinux and that is permanent until you remove the rule again.

vbox-setup.log inherits the SELinux context from the directory, /var/log, so that is normal. The program vboxdrv.sh was probably started from systemd and therefore inherits its context. Normally things started by systemd do not write any log files, so therefore do not need permission to create files in /var/log.

villykruse gravatar imagevillykruse ( 2018-10-01 18:16:51 -0500 )edit

One question. Probably I can google it, but to ask is easier. How can I remove the exceptions? The reason I ask that now, there is a kernel update but also an update for SELinux. So I want to update the system with those two lines of commands 'disabled' and to see what happens after the update of the kernel and SELinux.

tachi gravatar imagetachi ( 2018-10-09 13:57:13 -0500 )edit

You probably can't, at least not directly. Once you've added that rule, updates shouldn't bring it back because the executable's name doesn't change and that's what SELinux looks for.

sideburns gravatar imagesideburns ( 2018-10-09 14:05:31 -0500 )edit

You use semodule -r to remove a ruleset again. If the name of your rule module is my-vbox-rules you install it with

semodule -i my-vbox-rules.pp

and remove it again using

semodule -r my-vbox-rules

You can disable a module using semodule -d and re-enable it again using semodule -e.

In the file systems the rules are found in /var/lib/selinux/targeted/active/modules. Subdirectory 100 is for fedora provided rules, and 300 and 400 for your own modules.

villykruse gravatar imagevillykruse ( 2018-10-09 14:46:36 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-09-22 11:22:54 -0500

villykruse gravatar image

As suggested: run

ausearch -c 'vboxdrv.sh' --raw | audit2allow -M my-vboxdrvsh
semodule -X 300 -i my-vboxdrvsh.pp

vboxdrv.sh was not allowed to create the file vbox-setup.log probably in the /var/log directory.

It is a situation SELinux was not expecting, mainly because vbox is a non-fedora package. You could report this as a bug, but consider that the maintainer of the SELinux rules is overwhelmed by issues like this.

As SELinux is running in enforcing mode, I would expect that the vbox set-up did not work properly, and I would also expect more issues that would show up if you fix the first issue.

edit flag offensive delete link more

Comments

It took some time for the next kernel update. As you suggested I ran those two lines of commands. See my addition to my original question. And for now no further issues did show up.

tachi gravatar imagetachi ( 2018-10-01 17:08:45 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-09-22 07:52:31 -0500

Seen: 76 times

Last updated: Oct 01