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
          Opened by tom (archtom) - Thursday, 28 May 2015, 12:30 GMT
Last edited by Daniel Micay (thestinger) - Friday, 13 November 2015, 04:53 GMT
| 
 | 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
          
          
        Friday, 13 November 2015, 04:53 GMT
Reason for closing: No response
 
                      
...
[ 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
[ 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
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.
GRKERNSEC_CONFIG_VIRT_HOST
and
GRKERNSEC_CONFIG_VIRT_VIRTUALBOX
in the kernel or make it possible to activate it in any way.
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.
CONFIG_GRKERNSEC_VIRT_VIRTUALBOX=y
to /var/abs/community/linux-grsec/config.x86_64 and did another built ending up with the same result.
https://forums.grsecurity.net/
I don't think it's an Arch issue.
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