Re: [Lxc-users] CPU cgroup starts by itself
Dnia 2012-03-15, czw o godzinie 13:44 +0100, Goran Cetusic pisze: I have problems with starting containers in Linux Mint Debian Edition because /dev/cgroup/cpu is mounted by itself. I'm on Debian and I've ever had only two things mount any cgroups: 1. /etc/fstab (but you said it's not it) 2. /etc/cgconfig.conf (but of course it's nothing that a `grep -d recurse $some_keyword /etc` wouldn't show) Actually, a properly configured mount in either of those should enable LXC to work. And how to troubleshoot this at runtime? Try umounting the previously mounted filesystem and just mount where you need it. Shouldn't you be adding some options like -o cpu,freezer , too? You need specific cgroups mounted (like freezer) for LXC - at least that was the case when I last tried it I think. Oh, and I find that symlinking /etc/mtab to /proc/mounts helps a lot when dealing with cgroups. Hope that helps! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] how to use cpuset.shares?
Hi, From your original post, I conclude that you're after functionality akin to that of OpenVZ's cpulimit, that is, limiting the absolute amount of processing power (giving your container, for example, 1GHz out of a 2GHz processor core). LXC cpu.shares does not provide this kind of functionality - it is only used by the scheduler to assign resources proportionally. That is, if you only have 1 container running with 2 CPUs assigned, and cpu.shares is set to half, or quarter of the maximum, the container can still use 2 CPUs to their fullest if the machine is otherwise idle. If you're coming from an OpenVZ background, an easy comparison is that cpu.shares is functionally equivalent to cpuunits in OpenVZ. As far as I know, LXC doesn't implement CPU limiting (throttling) feature (neither do current OpenVZ releases; apparently it's hard to maintain). -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Mitigating LXC Container Evasion?
Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze: Had seen some previous discussions before, but are there any ways to mitigate this design vulnerability? http://blog.bofh.it/debian/id_413 Are there any workarounds? Thanks, - mdf The blog post explicitly mounts /sys... Why would you want your container to even have the capability to mount anything? If possible, drop CAP_SYS_ADMIN. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Root-less containers?
On Sun, 06 Feb 2011 18:23:41 +1300, Gary Ballantyne gary.ballant...@haulashore.com wrote: On 2/6/2011 3:56 PM, John Drescher wrote: Is this important if, say, a malicious user has access to a container? Or, can a container be configured such that they could do little harm? You can easily make a container have its own filesystem and no access to the host's filesystem or devices. Is that what you are getting at? Say we have a process P, which accepts an input file from the user. Further, suppose that P allows access to the command line -- and so a user can potentially execute any command in the container. To prevent malicious use, one option is to parse the input -- but running P in a container with minimal resources seems a much better option. I am trying to put a proof-of-concept together, and the root vs. normal user issue seemed relevant. Perhaps a better question would have been, what is the practical difference between the container running as a root user and a normal user? Right now, there is no big difference security-wise since a setuid() in the container, without working user namespaces, is equivalent to setuid() on the host system, and gaining root in the container can be done via the same exploits that would otherwise be possible on a non-virtualized system. Therefore, instead of thinking about running a container as root, one should ask how to properly separate the container from the rest of the system. This is, apparently, not as easy as it seems - there was a rootkit a few months ago that was capable of breaking out of OpenVZ and Linux-Vserver, and with the more loose security model of LXC currently, it seems trivial... To run an application in a container, use lxc-execute as always, but keep in mind that it does not make the system immune to attacks - currently, containers themselves can not be configured to do little harm. However, Linux kernel patches and LSM's can defend the host system as long as the kernel is kept intact. They do so from the level of the host system, as demonstrated in an IBM's article. Remember, the system is as secure as the weakest link. You need to both sanitize the application input and use isolation, not choose one over another. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc setup on a grsec enabled kernel
On Sun, 9 Jan 2011 13:25:53 +0100, Patrick Winnertz win...@der-winnie.de wrote: Hello, I've tried the last days hard to set up working lxc containers on a grsec enabled kernel. However I failed everytime with several error msgs and/or kernel oopses. After booting in the grsec kernel I've verified with gradm that RBAC is disabled to start the containers first: gradm -D lxc-start -n example however I get then first an error that /dev/pts can't be mounted and afterwards a kernel oops, which you can find attached to this mail - it seems to be some troubles with veth networking. I've straced the process and this is the output (strace-lxc1): 335:read(16, lxc-start: Operation not permitted - failed to mount a new instance of '/dev/pts' 336:lxc-start: failed to setup the new pts instance 337:lxc-start: failed to setup the container 344:write(2, failed to spawn 'web', 21failed to spawn 'web') = 21 358:write(2, Device or resource busy - failed..., 63Device or resource busy - failed to remove cgroup '/cgroup/web') = 63 After a reboot I tried again, but this time I switched into the learning mode of grsec.. now the kernel oops is gone, however I'm getting now this error msg (output from strace (strace-lxc2)): failed to create vethde3FDA-veth..., 64failed to create vethde3FDA-vethelGBjP : Operation not permitted) = 64 295:write(2, failed to create netdev, 23failed to create netdev) = 23 299:write(2, failed to create the network, 28failed to create the network) = 28 305:write(2, failed to spawn 'web', 21failed to spawn 'web') = 21 319:write(2, No such file or directory - fail..., 65No such file or directory - failed to remove cgroup '/cgroup/web') = 65 It would be nice if someone could give me hints or advices what is going wrong here and how to fix it. Full strace output of both lxc-start runs is also attached to the mail Greetings Patrick I can tell you I ran into similar oopses, haven't tested with learning mode though. What I did was disable CONFIG_PAX_KERNEXEC, which conflicts with CONFIG_PARAVIRT_GUEST and/or CONFIG_KVM_GUEST anyway (I was running the kernel under KVM; wish this conflict would be documented anywhere). After that, I could successfully start LXC guests without crashes. It was on 2.6.32.2-grsec if it matters. Yes, it is a workaround, and it does not help security of the system, but it's the best I can suggest. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
