Any way to disable all lxc apparmor security, I'm not interested in security in containers. I just want virtualization of different distros on a VM for demo applications not any security "benefits" since they stop me doing work. Currently apparmor is preventing me from using mounting NFS across containers. A fix for that would be good too but also I'd like minimal security annoyances since there is nothing to be secured in these systems at all. LXC containers we built with root.
mount -vvv 10.0.2.15:/var/shared /var/shared
...
mount.nfs: access denied by server while mounting 10.0.2.15:/var/shared
Mar 22 12:23:13 puppetdev kernel: [ 7638.020284] audit: type=1400 audit(1490181793.280:102): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-cgns" name="/var/shared/" pid=11846 comm="mount.nfs" fstype="nfs" srcname="10.0.2.15:/var/shared"
attempting to uninstal apparmor is not possible it wants to uninstall systemd too.
invoke-rc.d apparmor stop
/etc/init.d/apparmor stop
aa-complain /etc/apparmor.d/*
run still getting apparmor="DENIED"
lxc config set CONTAINER raw.lxc "lxc.aa_profile=unconfined"
Then restart the container and it won't have an apparmor profile anymore.
Though if all you care about is allowing nfs inside a privileged container, you can also just tweak the apparmor policy with:
printf "mount fstype=nfs,\nmount fstype=nfs4," | lxc config set CONTAINER raw.apparmor -
Hey just a note that in some work totally unrelated to this thread, I discovered that "lxc.aa_profile=unconfined" in an LXC config in an Ubuntu 17.04 Desktop or 17.10 Desktop environment will bork external monitors everytime you stop or start the container that has "lxc.aa_profile=unconfined" set. Just an FYI. Environment is LXC containers running on OpenvSwitch with a containerized DNS/DHCP (not using the default dnsmasq nor the lxcbr0).
That's not particularly surprising, especially if the container is privileged.
There aren't many init scripts that are particularly container aware during start and shutdown, the way things usually work is that those scripts deal nicely with failure and so attempt to reconfigure hardware but just aren't allowed to do so. Without apparmor in place, init scripts in privileged containers are actually allowed to directly interact with a number of subsystems (/sys is the likely bet in this case) and so may reset a number of devices.
lxc config set sentry raw.lxc 'lxc.aa_profile=unconfined'
Error: Initialize LXC: Failed to load raw.lxc
lxc --version
3.0.3
uname -a
Linux node0 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
lxc 20190416061644.973 ERROR confile - confile.c:parse_line:2262 - Unknown configuration key "lxc.aa_profile"
lxc 20190416061644.973 ERROR parse - parse.c:lxc_file_for_each_line_mmap:142 - Failed to parse config file "/tmp/lxd_config_532152568" at line "lxc.aa_profile=unconfined"
@xaionaro the key about aa_profile changed. The new key: lxc.apparmor.profile
You can use on /etc/pve/lxe/Container_ID.conf
lxc.apparmor.profile = unconfined
Most helpful comment
Then restart the container and it won't have an apparmor profile anymore.
Though if all you care about is allowing nfs inside a privileged container, you can also just tweak the apparmor policy with: