weixin_39579726
weixin_39579726
2021-01-08 13:47

Generated AppArmor profile prevents start of user unprivileged container

The template below is mostly useful for bug reports and support questions. Feel free to remove anything which doesn't apply to you and add more information where it makes sense.

Required information

  • Distribution: Debian
  • Distribution version: Buster/Testing
  • The output of
  • lxc-start --version lxc: 3.0.3
  • uname -a: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 (2019-05-15) x86_64 GNU/Linux

Issue description

In short, unprivileged containers can be run system wide via root but not via a user unless the container is run with AppArmor set to unconfined. I have followed the configuration guidance completely but was unable to successfully get the container to start.

Running lxc-start -n <container> as a user with lxc.apparmor.profile = generated the container fails to start and produces some output basically stating the same ("Failed to receive the container state" and "The container failed to start"). I'm running this in a virtual machine at present without ssh configured, so I can't copy the full output directly.

Running lxc-start -n <container> as a user with lxc.apparmor.profile = unconfined results in the container starting and functioning as expected.

Running sudo lxc-start -n <container> works as expected.

Steps to reproduce

  1. Configure system for unprivileged containers created by a user
  2. Create container as user set to use the generated AppArmor profile
  3. Attempt to start unprivileged container as user with generated AppArmor profile

该提问来源于开源项目:lxc/lxc

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

5条回答

  • weixin_39789979 weixin_39789979 4月前

    likely dup of https://github.com/lxc/lxc/issues/2778

    点赞 评论 复制链接分享
  • weixin_39579726 weixin_39579726 4月前

    Initially this was listed as a duplicate of #3030 but that doesn't seem to make sense because when I ls -al /var/lib/lxc and ls -al /var/lib/lxc/<container> the container directory and rootfs folder are owned by 100000 (id shifted).

    I also do not believe this is identical to #2778 either because I don't get audit messages in the system log mentioning networkd.

    What I do get, however, when running lxc-start configured to log debug messages to a file is a log entry something to the effect of (again, in VM so copying is not possible) ERROR apparmor - lsm/apparmor.c:apparmor_prepare:974 - Cannot use generated profile: apparmor_parser not available.

    I suspect this issue relates to how apparmor_parser is configured to work on Buster? You can only run the parser as root, but somehow this works on other distributions. Not sure what is going on with that?

    点赞 评论 复制链接分享
  • weixin_39688875 weixin_39688875 4月前

    Could be as simple as your user not having apparmor_parser in the PATH env variable. Some distros don't put /sbin and /usr/sbin in there.

    To be clear, unprivileged users cannot generate and load profiles, but you should be able to use the standard pre-existing ones or unconfined.

    点赞 评论 复制链接分享
  • weixin_39688875 weixin_39688875 4月前

    Marking as incomplete, the PATH issue is my best guess until then.

    点赞 评论 复制链接分享
  • weixin_39615219 weixin_39615219 4月前

    You are righe, on Debian buster apparmor_parser is not in the PATH, but even after I've added it the container won't start:

    
    ERROR    apparmor - lsm/apparmor.c:make_apparmor_namespace:761 - Permission denied - Error creating AppArmor namespace: /sys/kernel/security/apparmor/policy/namespaces/lxc-syncbox_
    ERROR    apparmor - lsm/apparmor.c:apparmor_prepare:980 - Failed to load generated AppArmor profile
    ERROR    start - start.c:lxc_init:899 - Failed to initialize LSM
    
    点赞 评论 复制链接分享

相关推荐