FS#45119 - [linux-grsec] virtualbox shared folder not mounting

Attached to Project: Community Packages
Opened by tom (archtom) - Thursday, 28 May 2015, 12:30 GMT
Last edited by Daniel Micay (thestinger) - Friday, 13 November 2015, 04:53 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Daniel Micay (thestinger)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

Description:

Hey,

I´m using archlinux 64 bit as a linux guest on an osx host in virtualbox (4.3.28) with all packages up to date. I managed to install the grsecurity hardened linux-grsec kernel.

I installed the virtualbox-guest-dkms and built the guest modules with the old gcc, got them to load and started VBoxClient-all.

Everything seems to work fine except of the mounting of the shared folder. It worked with the same settings before installing the grsec kernel and it works with the same dkms settings with the default kernel. That`s why I´m posting it with the kernel and not with the modules. The shared folder is set to automount and nothing else is configured in archlinux.

I did not change anything at the default grsec and pax preferences of the kernel. So I don`t know if it is a bug or just a setting. I posted my question at virtualbox forums and they closed the thread because they don`t support it. The archlinux

After starting the system (the shared folder is called "down") /media/sf_down ends up empty.

When running

VBoxService -f

as root I get the following error:

00:00:00.006995 automount Error: VBoxServiceAutoMountWorker: Could not mount shared folder "down" to "/media/sf_down": Protocol error (71)

When running

VBoxService -fvvv

it is getting more concrete:

00:00:00.010347 automount VBoxServiceAutoMountWorker: Shared folder mount prefix set to "sf_"
00:00:00.010443 automount VBoxServiceAutoMountWorker: Got 1 shared folder mappings
00:00:00.010795 automount VBoxServiceAutoMountWorker: Connecting share 1 (down) ...
00:00:00.012338 automount VBoxServiceAutoMountWorker: Messed up share name, re-trying ...
00:00:00.012610 automount VBoxServiceAutoMountWorker: Re-trying with old mounting structure ...
00:00:00.013087 automount Error: VBoxServiceAutoMountWorker: Could not mount shared folder "down" to "/media/sf_down": Protocol error (71)
00:00:00.013184 automount VBoxServiceAutoMountWorker: Mounting returned with rc=VERR_NET_PROTOCOL_ERROR

When trying to mount the share manually the same error persists.

sudo mount -t vboxsf -o uid=1000,gid=1000 down /media/sf_down

sbin/mount.vboxsf: mounting failed with the error: Protocol error

And yes, my user "tom" is in the vboxsf group and trying with root doesn`t work either.

I already tried changing the share name and I already tried deleting the share and re-adding it.

I googled a lot but couldn`t find an answer and I´m not sure if it`s just a setting that has to be done, a bug or anything else completely.

If you need any other info just let me know.

Thanks for every help.
This task depends upon

Closed by  Daniel Micay (thestinger)
Friday, 13 November 2015, 04:53 GMT
Reason for closing:  No response
Comment by Daniel Micay (thestinger) - Thursday, 28 May 2015, 17:03 GMT
Is there any output generated in the kernel log?
Comment by tom (archtom) - Thursday, 28 May 2015, 18:06 GMT
dmesg at the end shows the following:
...
[ 6.246590] VBoxService 4.3.28_OSE r100309 (verbosity: 0) linux.amd64 (May 14 2015 19:30:44) release log
00:00:00.000240 main Log opened 2015-05-28T18:01:05.367504000Z
[ 6.246702] 00:00:00.000617 main OS Product: Linux
[ 6.246785] 00:00:00.000722 main OS Release: 4.0.4.201505272113-1-grsec
[ 6.246829] 00:00:00.000768 main OS Version: #1 SMP PREEMPT Thu May 28 13:17:59 EDT 2015
[ 6.247060] 00:00:00.000989 main OS Service Pack: #1 SMP PREEMPT Thu May 28 13:17:59 EDT 2015
[ 6.247114] 00:00:00.001039 main Executable: /usr/bin/VBoxService
00:00:00.001042 main Process ID: 476
00:00:00.001045 main Package type: LINUX_64BITS_GENERIC (OSE)
[ 6.252340] 00:00:00.006229 main 4.3.28_OSE r100309 started. Verbose level = 0
[ 6.261375] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-5
[ 6.261404] VBoxGuestCommonIOCtl: HGCM_CALL: 64 Failed. rc=-5.
[ 6.261504] sf_read_super_aux err=-71
[ 6.261637] sf_read_super_aux err=-71
[ 6.261874] sf_read_super_aux err=-71
[ 6.261950] 00:00:00.015872 automount Error: VBoxServiceAutoMountWorker: Could not mount shared folder "down" to "/media/sf_down": Protocol error (71)
[ 6.321747] random: nonblocking pool is initialized
[ 6.531468] IPv6: ADDRCONF(NETDEV_UP): tap0: link is not ready
[ 6.579077] IPv6: ADDRCONF(NETDEV_CHANGE): tap0: link becomes ready
[ 6.630659] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 6.632963] device eth1 entered promiscuous mode
[ 6.649745] device tap0 entered promiscuous mode
[ 6.666216] br0: port 2(tap0) entered forwarding state
[ 6.666250] br0: port 2(tap0) entered forwarding state
[ 6.686771] br0: port 1(eth1) entered forwarding state
[ 6.686788] br0: port 1(eth1) entered forwarding state
[ 7.187095] floppy0: no floppy controllers found
[ 8.136917] grsec: denied kernel module auto-load of fuse by uid 1000
[ 8.411382] grsec: denied RWX mprotect of /usr/lib/mesa/libGL.so.1.2.0 by /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1[polkit-gnome-au:1020] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/xfce4-session[xfce4-session:986] uid/euid:1000/1000 gid/egid:100/100
[ 8.416920] grsec: denied RWX mprotect of /usr/lib/mesa/libGL.so.1.2.0 by /usr/bin/nm-applet[nm-applet:1033] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/xfce4-session[xfce4-session:986] uid/euid:1000/1000 gid/egid:100/100
[ 21.707572] br0: port 1(eth1) entered forwarding state
[ 21.707606] br0: port 2(tap0) entered forwarding state
Comment by tom (archtom) - Thursday, 28 May 2015, 18:07 GMT
and if I try to mount manually dmesg shows this:

[ 360.915265] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-5
[ 360.915290] VBoxGuestCommonIOCtl: HGCM_CALL: 64 Failed. rc=-5.
[ 360.915488] sf_read_super_aux err=-71
[ 360.915750] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-5
[ 360.915771] VBoxGuestCommonIOCtl: HGCM_CALL: 64 Failed. rc=-5.
[ 360.915983] sf_read_super_aux err=-71
[ 360.916241] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-5
[ 360.916262] VBoxGuestCommonIOCtl: HGCM_CALL: 64 Failed. rc=-5.
[ 360.916464] sf_read_super_aux err=-71
Comment by Daniel Micay (thestinger) - Thursday, 28 May 2015, 18:18 GMT
The fuse error can be fixed by loading it explicitly, although I don't think that's the issue here.
Comment by tom (archtom) - Thursday, 28 May 2015, 18:28 GMT
I loaded the module as root by typing

modprobe fuse

and tried manual mounting again, but it makes no difference.

I googled the sf_read_super_aux err=-71 error and it occured when some files were not linked correctly if I got that right. According to what I read in an older ubuntu version it had to be fixed like that:

sudo ln -s /opt/VBoxGuestAdditions-4.3.10/lib/VBoxGuestAdditions /usr/lib/VBoxGuestAdditions

But I don`t know if this helps here.
Comment by tom (archtom) - Friday, 29 May 2015, 09:14 GMT
Perhaps it helps integrating

GRKERNSEC_CONFIG_VIRT_HOST
and
GRKERNSEC_CONFIG_VIRT_VIRTUALBOX

in the kernel or make it possible to activate it in any way.
Comment by tom (archtom) - Friday, 29 May 2015, 09:14 GMT
If you need me to test anything just let me know. Thanks for your help.
Comment by Daniel Micay (thestinger) - Friday, 29 May 2015, 21:32 GMT
I can't enable GRKERNSEC_CONFIG_VIRT_VIRTUALBOX because it would disable RANDKSTACK which is an important security feature. That might be what's causing the issue here, but I'm not sure.
Comment by Daniel Micay (thestinger) - Friday, 29 May 2015, 21:33 GMT
You could try rebuilding the package with RANDKSTACK disabled in config / config.x86_64.
Comment by tom (archtom) - Saturday, 30 May 2015, 13:30 GMT
I had never done this before so I had to do some reading and waiting for a long build time in the vbox...

I did the following and nothing changed. Did I do anything wrong?

# installation
yaourt -Sy abs ccache --noconfirm
abs
# tree will be created under /var/abs

# creating build directories
rm -rf /data/build/*
mkdir -p /data/build/
mkdir -p /data/build/packages
mkdir -p /data/build/sources
mkdir -p /data/build/srcpackages
mkdir -p /data/build/makepkg
chown -R root:extrasmbuser /data/build
chmod -R 770 /data/build

# configuring makepkg
sed -i '/^BUILDENV=/s/!ccache/ccache/' /etc/makepkg.conf
sed -i '/^COMPRESSXZ=/s/(xz/(xz -T 0/' /etc/makepkg.conf
echo "PKGDEST=/data/build/packages" >> /etc/makepkg.conf
echo "SRCDEST=/data/build/sources" >> /etc/makepkg.conf
echo "SRCPKGDEST=/data/build/srcpackages" >> /etc/makepkg.conf
echo "BUILDDIR=/data/build/makepkg" >> /etc/makepkg.conf

# changing configuration for the package
sed -i 's|^.*CONFIG_PAX_RANDKSTACK=.*|CONFIG_PAX_RANDKSTACK=n|' /var/abs/community/linux-grsec/config.x86_64

# changing directory to package
cd /var/abs/community/linux-grsec

# updating checksums after changing the config file
su - tom -c "updpkgsums /var/abs/community/linux-grsec/PKGBUILD"

# building the package
makepkg -cs --cleanbuild
makepkg -i

After that I built the modules and rebootet.

Comment by tom (archtom) - Saturday, 30 May 2015, 15:25 GMT
I did a second try with adding
CONFIG_GRKERNSEC_VIRT_VIRTUALBOX=y
to /var/abs/community/linux-grsec/config.x86_64 and did another built ending up with the same result.
Comment by Daniel Micay (thestinger) - Sunday, 14 June 2015, 20:07 GMT
The next step would be trying with various other features disabled (turning off half to narrow down where the cause is, then repeat with the smaller set) or trying with just the PaX patch instead of grsecurity.
Comment by Daniel Micay (thestinger) - Saturday, 04 July 2015, 02:27 GMT
If you still run into this with the most recent version you should report it upstream:

https://forums.grsecurity.net/

I don't think it's an Arch issue.
Comment by tom (archtom) - Sunday, 05 July 2015, 14:52 GMT
sorry, I didn`t have much time to try the last days.

Last time I tried I put together a small script (I´m not an expert, so I hope it`s ok) for fast trying with an up to date vbox image. I just ran the attached script and ended up with the same not working setup. It would be very nice if you could have a look at the script if I´m doing anything wrong there. If not I´ll post in the grsecurity forum.

thanks for all the help

Comment by Daniel Micay (thestinger) - Sunday, 19 July 2015, 17:24 GMT
As long as you can't reproduce it with the vanilla kernel, I'm quite sure it's an upstream grsecurity / PaX issue.
Comment by Daniel Micay (thestinger) - Friday, 16 October 2015, 17:08 GMT
Is this still an issue with the current patch? There was a change relevant to VirtualBox.
Comment by Daniel Micay (thestinger) - Friday, 16 October 2015, 17:08 GMT
4.2.3.201510130858-1
Comment by Daniel Micay (thestinger) - Friday, 13 November 2015, 04:53 GMT
Please open another issue if this is still a problem. Going to assume that this was fixed at some point. Either way, it's probably just an incompatibility with a feature that's only fixable by disabling the feature or patching the out-of-tree drivers. It's not always possible to have good support for out-of-tree drivers in grsecurity.

Loading...