Page 1 of 4 123 ... LastLast
Results 1 to 10 of 31

Thread: LXD Based Container For Desktop Applications - Some Success - Help (need more)

  1. #1
    Join Date
    May 2008
    Beans
    94

    LXD Based Container For Desktop Applications - Some Success - Help (need more)

    I'm trying to use an LXD based container to run desktop applications on my standard desktop, in much the same way as this
    https://www.stgraber.org/2014/02/09/...in-containers/
    I know about, and use firejail, but like to use this method for operational reasons. I feel the solution is so close .. I'm just missing something to make it work.
    I can run a complete session via X2Go or VNC (tigervnc if you want to run Unity or KDE.... but any VNC for Mate, LXDE etc) .. but this is NOT what I want for my intended use case (i want the appearance of desktop integration)

    So far I can run an application in a Xephyr screen (essentially an X "subscreen") but not on the host desktop (ultimate aim). Xephy afaik is X avvess on a subscreen, so if this works, why doesn't access to the host screen (DISPLAY=:0 or DISPLAY=:0.0) ?

    For a Xephyr screen
    1) Install Xephyr
    2) run Xephyr with "Xephyr -a -br -noreset -name xephyr_screen_101 -title Browse_Danger -screen 1800x1080 :101"
    3) log into the container and run the program, directing output to display 101 ie.
    a) lxc exec <container-name> bash
    b) DISPLAY=:101 firefox
    4) Firefox will duly appear on the Xephyr screen

    To run this from outside the container
    1) Create shell program inside the container, containing just the command in 3b ie.
    #!/bin/bash
    DISPLAY=:101 firefox
    2) Make the program executable ie. chmod ug+x <shell-program-above> and possibly change ownership
    2) Execute with
    lxc exec <container-name> su <user name> -- <shell-program-above>

    The minimum config required to make this work seems to be

    Code:
        withname: <container-name>
        profiles:
        - default
        config:
         raw.lxc: lxc.aa_profile=lxc-container-default-with-mounting
        devices:
         root:
           path: /
           type: disk
         x11-unix:
           path: /tmp/.X11-unix
           source: /tmp/.X11-unix
           type: disk
        ephemeral: false

    by adding a few more mounts we can get a full desktop for user = <user> to run in Xephyr eg.

    Code:
     
        devices:
          dri:
            path: /dev/dri
            source: /dev/dri
            type: disk
          iceauthority-<user>:
            path: /home/<user>/.ICEauthority
            source: /home/<user>/.ICEauthority
            type: disk
          root:
            path: /
            type: disk
          x11-unix:
            path: /tmp/.X11-unix
            source: /tmp/.X11-unix
            type: disk
          xauthority-<user>:
            path: /home/<user>/.Xauthority
            source: /home/<user>/.Xauthority
            type: disk
        ephemeral: false
    Obviously we needed to have added <user> first and ensure the home directory was created (should be created when using "adduser") and then run the desktop whilst logged in as <user>

    No matter what I do I cannot get a program to display on the host screen eg. DISPLAY=:0 firefox. This return an error message

    Code:
     
        $ DISPLAY=:0 firefox
        No protocol specified
        Failed to connect to Mir: Failed to connect to server socket: No such file or directory
        Unable to init server: Could not connect: Connection refused
        Error: cannot open display: :0
    These messages turn up in the host dmesg ... but I'm a bit suspicious of the apparmor messages, they may be red herrings (should I be?)

    Code:
      
        508499.335953] audit: type=1400 audit(1469067007.731:3225): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxd-xenial-browse-danger-test_</var/lib/lxd>" pid=29368 comm="apparmor_parser"
        [508499.342613] device vethO9YPDN entered promiscuous mode
        [508499.342650] IPv6: ADDRCONF(NETDEV_UP): vethO9YPDN: link is not ready
        [508499.385405] eth0: renamed from vethE393S7
        [508499.408826] IPv6: ADDRCONF(NETDEV_CHANGE): vethO9YPDN: link becomes ready
        [508499.408877] lxcbr0: port 4(vethO9YPDN) entered forwarding state
        [508499.408886] lxcbr0: port 4(vethO9YPDN) entered forwarding state
        [508499.438414] audit: type=1400 audit(1469067007.835:3226): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-with-mounting" name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd" fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
        [508499.438529] audit: type=1400 audit(1469067007.835:3227): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-with-mounting" name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd" fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
        [508514.445340] lxcbr0: port 4(vethO9YPDN) entered forwarding state
    and from the host Syslog

    Code:
        Jul 21 12:10:07 virt-host kernel: [508499.438414] audit: type=1400 audit(1469067007.835:3226): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-with-mounting" name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd" fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
        Jul 21 12:10:07 virt-host kernel: [508499.438529] audit: type=1400 audit(1469067007.835:3227): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-with-mounting" name="/sys/fs/cgroup/systemd/" pid=29377 comm="systemd" fstype="cgroup" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
    If I then change the apparmor profile to unconfined and re-run, I see the following in the host dmesg

    Code:
        [508796.382044] audit: type=1400 audit(1469067304.766:3230): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=5259 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
        [508796.395527] audit: type=1400 audit(1469067304.782:3231): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=5266 comm="cups-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
        [508796.395578] audit: type=1400 audit(1469067304.782:3232): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=5265 comm="cups-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
        [508796.395778] audit: type=1400 audit(1469067304.782:3233): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=5265 comm="dbus" requested_mask="r" denied_mask="r" fsuid=7 ouid=0
        [508796.398616] audit: type=1400 audit(1469067304.782:3234): apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd" name="/etc/ld.so.preload" pid=5266 comm="dbus" requested_mask="r" denied_mask="r" fsuid=7 ouid=0
    It's worth noting that the legacy LXC approach outlined in the first link above still works on this host (so I have a legacy style lxc container which works). The legacy style config is notably different in its id maps

    Code:
     
        lxc.id_map = u 0 100000 1000
        lxc.id_map = g 0 100000 1000
        lxc.id_map = u 1000 1000 1
        lxc.id_map = g 1000 1000 1
        lxc.id_map = u 1001 101001 64535
        lxc.id_map = g 1001 101001 64535
    vs the default.
    If I try to use the above map, the container won't start. I can use the following map (created a new profile and then created the test container using that profile + default) and it will start, but doesn't address the access problem

    Code:
     
        lxc.id_map = u 400000 1000 1
        lxc.id_map = g 400000 1000 1
    I also tried adding

    Code:
     
        lxc.id_map = u 1001 401001 64535
        lxc.id_map = g 1001 401001 64535
    But that didn't help and the 1000 1000 mapping prevented the container from starting
    It seems odd that Xephyr screens are painted ok but the host screen :0 isn't .... And if it's an apparmor problem, how come "unconfined" is confining it ?

    DOES ANYONE HAVE ANY INSIGHTS SUGGESTIONS ?

  2. #2
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    TL;DR .... check out firejail. Makes it trivial to run apps, including GUIs in a different container. Wasn't in 14.04, but was available in 16.04.

  3. #3
    Join Date
    May 2008
    Beans
    94

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    thanks Fu,
    as noted I know of and use Firejail (see line 3 in initial note). This use case requires more than Firejail offers

    I've also successfully used X2Go and TigerNVC.
    I tried Spice (unsuccessfully so far).

  4. #4
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 20.04 Focal Fossa

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    I realize this is borderline necroposting but the OP's question remains relevant and topical, and the answers out there are both exceedingly obscure and arcane.

    The main issues are these:

    1. So far, almost all of the tutorials/user guides for LXD have been geared to a CLI server environment, since LXD's main application up to now has been massive industrial-scale usages like cloud computing.
    2. But there is a very big need (and case) for use of LXD on the desktop.
    3. It is especially useful for isolating/containing/sandboxing GUI apps on machines not powerful enough to run VMs.
    4. Moreover, because it runs at bare metal speed and efficiency, it is superior to VMs in so many other respects.
    5. Ideally, one could run LXD-contained apps with the appearance of native desktop apps instead of boxed into a remote desktop window.

    After days of Googling and experimenting, I've cobbled together the steps needed to implement what @redger set out to do:

    1. The key step is to create the container with display output already set to ${DISPLAY}. This is done as follows:
      Code:
      lxc launch ubuntu:16.04 name_of_container -c environment.DISPLAY=${DISPLAY}
      Thereafter, all GUI output will be directed to the user's primary display. Theoretically, by creating containers with display outputs ≠ ${DISPLAY}, we could launch whole contained DEs into other TTYs and use up those higher slots like <Ctrl>+<Alt>+<F8>…<F12>. This has long been a goal of mine, but I'm digressing.
    2. Next, edit your host X11 config to allow X11 forwarding. In Ubuntu Xenial, the file is /etc/lightdm/users.conf. Add the following section:
      Code:
      [security]
      DisallowTCP=false
    3. Next, set X on the host to run promiscuously with:
      Code:
      xhost +
      This will disable whatever rudimentary security/privacy measures X provides, but since X is a security/privacy sieve anyways, it really isn't much of a loss. This must be done. Otherwise, xhost will deny connection access to the container. Setting xhost to promiscuous must be done every time you boot because it resets to secure mode after every reboot. I suppose this can be changed permanently in some config file, but that will require more research.
    4. Then:
      Code:
      lxc config device add name_of_container x disk source=/tmp/.X11-unix/ path=/tmp/.X11-unix/

    To test this, just install a GUI app into the container that isn't part of a default install: say, midori:
    Code:
    lxc exec name_of_container -- apt install midori -y
    Code:
    lxc exec name_of_container midori
    On my system, it runs perfectly.

    I suppose that it's possible to change the environment.DISPLAY value in an existing container, but I haven't figured out how to do that yet.

    It is worth noting that @redger's remote desktop method has one immense advantage over the method just outlined above: it is far more secure. A remote desktop like Xephyr runs as a separate xsession. Therefore, quite aside from not having to disable xhost, apps of distinct xsessions have a much harder time peering into another xsession than they do on a commonly shared xsession. This alone makes the remote desktop approach superior for anything that is sensitive. Since one of the purposes of containment is to sandbox, it seems counterproductive to run a contained app in an environment that compromises such containment. This is another example of why Wayland or Mir is being developed to replace X.

    BTW, the above info was mainly gleaned from Stephane Graber's following github post: https://github.com/lxc/lxd/issues/11...ment-239902931
    It's the only clear example that I could find.
    Last edited by DuckHook; January 29th, 2017 at 09:55 AM. Reason: Added missing config info

  5. #5
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    It isn't necroposting when it is THIS useful!

    Using xhost + is really bad. We used to change people's root window background if they had that allowed and security could never find a trace. There is a huge difference between allowing any remote X connection and allowing the host OS IP via X. xhost + {local IP} shouldn't be hard for anyone going through these steps to add and would make X/Windows 254x more secure.

    I use remote X so much that until any other X/Windows replacement supports it, I just cannot consider switching. The machine I'm physically using is seldom very powerful whereas the there are other networked systems that have lots and lots of power.

    That doesn't take away the usefulness of this technique at all. Plan to play with it this week.
    BTW, the SELF Basic Container Security presentation was just posted here: https://www.youtube.com/playlist?lis...tb7RIjEJtkYYC5 with a number of other container best-practice videos.

  6. #6
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 20.04 Focal Fossa

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    Quote Originally Posted by TheFu View Post
    Using xhost + is really bad…There is a huge difference between allowing any remote X connection and allowing the host OS IP via X.
    I agree it's bad. But I haven't been able to get it to work using any variation or combination of xhost + {local IP}
    xhost + {local IP} shouldn't be hard for anyone going through these steps to add and would make X/Windows 254x more secure…Plan to play with it this week.
    Please let us know if you solve the xhost + problem. I will note that disabling xhost security is very problematic in a multiuser work environment, but in a reasonably well-secured single-user home environment (such as mine), it isn't as much of an issue. Still, it does not constitute good practice, and for that reason alone, I would like to get to the bottom of it.
    BTW, the SELF Basic Container Security presentation was just posted here: https://www.youtube.com/playlist?lis...tb7RIjEJtkYYC5 with a number of other container best-practice videos.
    Thanks for the link!

  7. #7
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 20.04 Focal Fossa

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    We're getting closer!

    A better solution is:
    Code:
    xhost +local:
    This is probably still broader than TheFu would like, but at least it stops any network access to X. As already mentioned, if strict X containment is a requirement, then don't use this method to start with and use a remote desktop instead.
    Last edited by DuckHook; January 29th, 2017 at 07:11 PM. Reason: Accurate description

  8. #8
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 20.04 Focal Fossa

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    Thought I would provide update:

    While the above procedures work graphically, I've hit a on the audio. Despite days of experimentation, I haven't been able to map container sound onto host pulseaudio. This is a known issue with LXD and the desktop, and there's very little on the net on how to put it all together. If others have had success, please do share.

    Here's what I've done so far:

    1. Added to host /etc/pulse/system.pa:
      Code:
      load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;10.41.45.0/24
      auth-anonymous=1
      load-module module-zeroconf-publish
    2. Created in my ${HOME} directory the file .asoundrc with the following:
      Code:
      pcm.!default {
       type plug
       slave.pcm {
       type hw
       card 1
       device 0
       }
      }
      
      defaults.ctl.card 1
      Your card and device numbers may be different.
    3. Installed paprefs in the host → Under "Network Server" tab → checked "Enable network access to local sound devices", and "Don't require authentication".
    4. In container, added both root and ubuntu user to the groups pulse, audio and pulse-access

    So far, no joy.

  9. #9
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 20.04 Focal Fossa

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    There is this directly from Stephane Graber: https://github.com/lxc/lxd/issues/23...ment-245115628

    Of especial note is his comment:
    …it sounds like you really should stick to LXC itself as that's the only tool which lets you create containers as your own user right now and so is a good fit for this use case.
    …so I am getting discouraged. It appears that LXD is designed from the ground up to remap IDs, NAT, apparmor and otherwise box the container so robustly that the only way to get it to work with apps "naturally" is to open up holes so large that it defeats the point and purpose of containing the app in the first place. First, I had to open up xhost. Now I've got to poke holes in pulseaudio. Not feeling good about this security-wise.

    Will continue playing with it, but has dropped significantly in priority. If OP is still reading, did audio work with Zephyr?

  10. #10
    Join Date
    Jul 2013
    Beans
    57

    Re: LXD Based Container For Desktop Applications - Some Success - Help (need more)

    LXD (LXC v2) is terrific and a big improvement over LXC v1.

    It supports so much more including local & remote servers, CRIU, btrfs/zfs, new networking features like VLAN, VxLAN etc.

    If you use Reddit check out the LXD sub-reddit as there is a lot of information there.

    https://www.reddit.com/r/LXD/

    Also, I'd highly recommend joining the lxc-users mailer alias as the LXD (and LXC) developers monitor it and answer questions daily.

    https://lists.linuxcontainers.org/listinfo/lxc-users

    Finally, Stephane Graber's (he's the lead LXD dev) 12+ part Blog post on LXD is pretty great in explaining alot of what its capable of and how to do things.

    https://stgraber.org/2016/03/11/lxd-...st-series-012/

Page 1 of 4 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •