First of all, an "unprivileged" container is still pretty insecure if you don't have a proper Linux Security Module (LSM) enforcing Mandatory Access Control to restrict what the container can do.
LXD takes a decent stab at integrating the AppArmor LSM and applies it pretty well to secure and isolate unprivileged LXD guests out of the box, especially on Ubuntu 16.04+ using recent LXD versions. Not so much LXC; please search the list archives for this question being asked many many times (at least once a week) if you are not 100% clear on the difference between LXC and LXD. You could probably further improve upon and lock down the rules LXD applies to a container out of the box if you knew more specific details about exactly what the container *should* (and shouldn't) be able to do. You could provide these rules to AppArmor, which if you were thorough would really reduce the usability of any exploits in the container. That said, any mechanism that enables an unauthorized user to execute arbitrary machine code (shell code) on the CPU, where the exact machine code is controlled by the attacker -- like injecting their own binary -- is inherently dangerous, mainly because any breach into kernelspace allows extremely privileged access to the system. If this were a rarity, then we wouldn't (still) be seeing Android phones getting rooted despite manufacturers' best attempts to keep their kernel patched and impose Mandatory Access Control, like Samsung Knox. LXC and LXD are really good for situations where you at least partially trust the container not to maliciously attempt to break into the host OS. But it's actually very difficult, apart from hardware virtualization (putting your NTP server in its own domU), to prevent a *compromised* process from eventually privilege-escalating itself up to gaining root on the physical OS (the dom0, in your case). And even then, Xen has had the occasional VM-busting exploit. The attack surface is large enough, and the number and rate of vulnerability discovery in the past has been high enough, that if someone is running arbitrary code on your box, there's a good chance that -- depending on their level of sophistication -- they'll be able to escalate privilege in some way... almost certainly by a little, and possibly by a whole lot. This is independent of whether you're running LXD, LXC or hardware virtualization. You _could_ call LXD and its AppArmor profiles "defense in depth" compared to running an NTP server directly on the dom0, but I certainly wouldn't claim that it's an impenetrable fortress designed from the ground up to be fully isolated from the host and to indefinitely contain the damage of a malicious user / compromised process. Nor would I claim it would slow down an advanced threat by very much. It was really designed with convenience in mind, and its security is slowly improving, but I wouldn't say it's yet rigorous enough that a sufficiently-paranoid military or intelligence organization would trust it; so if they wouldn't trust it, you might not want to yet, either. Sean On Mon, Apr 24, 2017 at 11:58 PM, Mike <[email protected]> wrote: > I need to run NTP on a Xen dom0. (I'm running it in the dom0 in order > to have all the Xen guests and host synchronized.) I'm concerned about > remote code execution exploits via buffer overflows, for example. > I have no experience with unprivileged LXCs yet. > > Would it provide useful protection of the dom0 to run the NTP daemon in > an LXC? Or should I not bother, because the daemon would have no lesser > privileges anyway? > > I was trying to do this, but was encountering some conflicts with > /proc/xen in starting the LXC. (I didn't encounter this in a domU.) > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
