SELinux alert caused by VirtualBox after every kernel update [closed]

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

tachi
31 ●3

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 reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by tachi
close date 2018-11-10 07:02:23.806252

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 ( 2018-09-22 13:09:16 -0500 )edit

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 ( 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 ( 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 ( 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 ( 2018-10-09 14:46:36 -0500 )edit

see more comments

answered 2018-10-29 18:23:44 -0500

tachi
31 ●3

I suppose in any case the temporary solution is to run the suggestion provided by SELinux itself until a fix is provided as it is in this example.

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

The first line creates two files (my-vboxdrvsh.pp & my-vboxdrvsh.te) which is needed by the second line. For testing purposes I would turn off above rules before updating SELinux and in this case the kernel.

semodule -X 300 -r my-vboxdrvsh

If you get the same warning from SELinux after an update you can run again:

semodule -X 300 -i my-vboxdrvsh.pp

Some permissions are not turned on by default, so for this example you would need to run:

setsebool -P use_virtualbox 1

For novice users, like me, I would recommend to install policycoreutils-gui which provides a very handy graphical tool to manage SELinux.

I would like to thank villykruse providing the explanations and updates. I understand the concept of SELinux a lot more now. It has become less of a black box to me now.

edit flag offensive delete link

Comments

If you do forget to set setsebool -P use_virtualbox 1 then you will get with the latest update of SELinux a suggestion from SELinux itself to set the previous mentioned setting. With this last note I consider my question as answered and closed.

tachi ( 2018-11-09 18:57:15 -0500 )edit

add a comment

SELinux alert caused by VirtualBox after every kernel update [closed]

Closed for the following reason the question is answered, right answer was accepted by tachi
close date 2018-11-10 07:02:23.806252

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

SELinux alert caused by VirtualBox after every kernel update [closed] edit

Closed for the following reason the question is answered, right answer was accepted by tachi close date 2018-11-10 07:02:23.806252

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

SELinux alert caused by VirtualBox after every kernel update [closed]

Closed for the following reason the question is answered, right answer was accepted by tachi
close date 2018-11-10 07:02:23.806252