From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6486351797115944960 X-Received: by 10.28.54.38 with SMTP id d38mr635375wma.3.1510476803056; Sun, 12 Nov 2017 00:53:23 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.162.137 with SMTP id s9ls6122140wra.7.gmail; Sun, 12 Nov 2017 00:53:22 -0800 (PST) X-Google-Smtp-Source: AGs4zMbi5hPXquiseXYAS17+f1ArWX2wr6AaLBUjymTa880iGPhZ/lvX4UTBCe1ywz6FYfJBzUvQ X-Received: by 10.28.190.7 with SMTP id o7mr378498wmf.2.1510476802679; Sun, 12 Nov 2017 00:53:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510476802; cv=none; d=google.com; s=arc-20160816; b=AJBDL0JavN1jueYJb94lJBT4xDmSx/v0uuJuEcKO1hVVsJe9Wboq5uyRDqHZiiM4XQ rNjjKX1LPmKMlrs9EDNWvluAXDHKrrt1/hYBCIsswSnPY5H/UA3nFoSKkXgX/oZ+OkgT pC24iD/llIz8L+HDM0SK9mXF6vDKDUaSfLy4N5f7cghHUTkjYxiOkPm6cNpqFsdO5PuN i+tsd0YrHo+UJagDK8qgwabr0dtRx4Ntffwc2w4hSKOvEkns+obBJT/Twn8WpPWBJ2Q0 YDwubnKfCJu1Qirhwh6YWl9R37ZOZaddRuvRtf9UUqM/1DcwTSJAzwZn91/lG9KSYkox UjrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:references:in-reply-to:date:to:from:subject:message-id :arc-authentication-results; bh=xsiAlc0MGOnjeXKw+3vIrSEfLd7MJ6QMLonPLFL2Idg=; b=A8PIlpr8Sy3cQzHpiwQPsMOenIqxkW16yYjhmm32MK6BMkQB3+al6v9FtJur4oqhvQ 2N6D/jiuT3Og2w72bAW83IFPm2TdckwvwqUGLedGBJlVz2jAT+V5gcp7tOdPrW50lrBE lxaf7zykcVBU55E/O8TmS6B4wDZml3TU8ndatByhI+TzHtla8tFez7zt/fzF9l1IQk4j F67HgJOoDv83x12+lU3b2F3ne5vetYHEXiT1azfXJsJF/sw1ydfiWBB9HfUE762TXvGi IDIl9nH+X6QH6KxiERNaQ11dh1nLJY2zWxxfndfqcA8l+WkLaFqq9eCOjVKzEztGAq7D y+bQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.10]) by gmr-mx.google.com with ESMTPS id f8si1014780wrf.0.2017.11.12.00.53.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 00:53:22 -0800 (PST) Received-SPF: neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) client-ip=212.18.0.10; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3yZSGp2WBhz1qyvy; Sun, 12 Nov 2017 09:53:22 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 3yZSGp25Htz1yg4c; Sun, 12 Nov 2017 09:53:22 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id Xph_X0q1b1K4; Sun, 12 Nov 2017 09:53:20 +0100 (CET) X-Auth-Info: 1eXVn/jTGPF/kCKabmU9kubLCRWD6zlOnt9eE32lhOo= Received: from Orrorin.lan (dslb-084-056-059-158.084.056.pools.vodafone-ip.de [84.56.59.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sun, 12 Nov 2017 09:53:20 +0100 (CET) Message-ID: <1510476795.3306.23.camel@denx.de> Subject: Re: PRoot Isar summary From: Claudius Heine To: Benedikt Niedermayr , Alexander Smirnov , Jan Kiszka , isar-users@googlegroups.com Date: Sun, 12 Nov 2017 09:53:15 +0100 In-Reply-To: <9950a893-2f7b-c841-7db2-b8e7926b1d88@googlemail.com> References: <1496e693-490f-16d6-0957-c9281ed7dd3e@ilbers.de> <7d48c419-34e0-b63a-2542-85a1c03ec764@ilbers.de> <9950a893-2f7b-c841-7db2-b8e7926b1d88@googlemail.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-kLNwQNnCxfKZ/qqWUkho" X-Mailer: Evolution 3.26.2 Mime-Version: 1.0 X-TUID: xKHo4ado3J7v --=-kLNwQNnCxfKZ/qqWUkho Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, On Sat, 2017-11-11 at 18:22 +0100, 'Benedikt Niedermayr' via isar-users=20 wrote: > Am 10.11.2017 um 20:42 schrieb Alexander Smirnov: > > Hi, > >=20 > > On 11/10/2017 09:59 PM, Jan Kiszka wrote: > > > On 2017-11-09 10:57, Alexander Smirnov wrote: > > > > Hello everybody, > > > >=20 > > > > I've tried to completely switch Isar to PRoot, so here are the > > > > problems > > > > I've faced with: > > > >=20 > > > > 1. PRoot doesn't work with UID/GID, all the files in PRoot are > > > > owned by > > > > root. The command 'chown' doesn't have any effect. > > > >=20 > > > > 2. Some system commands are failed in PRoot: passwd, chpasswd. > > > > I see > > > > message: System error, no other clues (but for Wheezy these > > > > commands=20 > > > > work). > > > >=20 > > > > 3. mkfs.ext4 doesn't work under proot, lots of files are > > > > dropped in > > > > resulting image. > > > >=20 > > > > So, summary: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > 1. PRoot could be an intermediate option for: > > > > + Buildchroot creation. > > > > + Packages building. > > > > - Drawback: works slowly. > > >=20 > > > Aren't issues 1 and 2 from above affecting these use cases as > > > well? > > >=20 > >=20 > > For now I don't have any facts about problems with buildchroot, but > > my=20 > > test includes only 'hello' and 'example-raw' applications. > >=20 > > - Regarding UID/GID, what I've seen for now, these manipulations > > are=20 > > done in postinst scripts. > > - Passwd/chpasswd commands are also used in postinst scripts (for=20 > > example initrd package), there is no need to have passwords in=20 > > buildchroot because we are working under root. > >=20 > > So, roughly speaking, buildchroot is only needed to compile and > > pack=20 > > the binary package, what doesn't require multi-UID/GID and > > passwords=20 > > support. > >=20 > > But for sure, it needs to build much more real packages to have > > more=20 > > precise statistics. :-( > >=20 > > So I've created dedicated branch 'asmirnov/proot' for possible=20 > > experiments in future. > >=20 > > > >=20 > > > > 2. For image generation the other tool should be considered. > > > >=20 > > >=20 > > > What is plan B now? Plan C remains falling back to VM builds, I > > > suppose. > >=20 > > So there are 2 options remain for evaluation: > > - fakeroot > > - pseudo > >=20 > > I'd like to evaluate these tools for the features, that are > > uncovered=20 > > now: > >=20 > > - rootfs with UID/GID support: in general PRoot is able to > > generate=20 > > multistrap rootfs with just *upacked* Debian packages, all the=20 > > problems occur when I try to run 'dpkg-configure -a' inside this > > rootfs. > >=20 > > - ext2fs image generation (AFAIK this already is supported by > > Yocto,=20 > > but unfortunately I don't know too much, I need to take a look > > first). > >=20 > > From this evaluation I'd like to get two points: > >=20 > > 1. Could we somehow implement quick PoC to drop 'sudo' for Isar. > > This=20 > > PoC could be based on several tools in parallel. > >=20 > > 2. If the item above is possible - then choose one dedicated tool > > and=20 > > try to adapt it for our needs. > >=20 > > Alex > >=20 >=20 > Ok bad news, but I faced the same problems, when trying to use one > of=20 > these tools. Each tool has own drawbacks and benefits, but no tool=20 > combines multiple drawbacks to fit our needs. >=20 > I don't want to bother you, but why can't we try to focus on running=20 > builds with docker support? >=20 > Create a wrapper around "bitbake" which first performs a docker=20 > container setup and then runs the bitbake build. >=20 > Using such wrapper can make the docker thing almost transparent. We already using such a wrapper, that does sort of what you want: https://github.com/siemens/kas It does not wrap around docker itself, but around bitbake and a ready prepared docker container is available: https://hub.docker.com/r/kasproject/kas-isar/ Patches and feature requests welcome. > I know there are some problems getting a docker container secure, > but=20 > maybe a focus on trying to get a docker based isar build secure, is=20 > easier to reach than the our current approaches? >=20 > It is possible to drop some capabilities for docker in order to make > it=20 > more secure (e.g. don't allow to create dev files). >=20 > A mount command is also not required since, new versions of mkfs > have=20 > the "-d" option included (specifiy a directory, which copied into > the=20 > filesystem image). So no sys_admin capabilities would be needed. >=20 > It is also possible to customize other things within the container > to=20 > make it more secure: >=20 > - Add only required commands to sudoers file. Problem here are the additional layers that might add additional programs that need to be run with root privileges. That is not something that can be controlled easily. >=20 > - Modify permissions to files/directories. Who cares if the container gets corrupted, of course we should mount every 'source' directory into the container read-only. >=20 > - Think about which commands within isar really need root > privileges,=20 > and drop those. Don't think that really helps, because there are so many programs that might require root privileges, depending on the custom recipe. Also if 'postinst' is run as root, you could put any command there that is run as root user. >=20 > I think, if somebody seriously wants to exploit the container, he > will=20 > also reach that with a non-root based build. If we are giving up on trying to remove the root dependency of the build, then I would rather go with preparing a vagrant file instead of a container. We would have better isolation there and don't really need to care about capabilities. Otherwise I would still suggest to patch proot to support the additional syscalls (chown, chmod, mknod, ...), save those into a file and allow proot to load this file via a parameter. Then we would have something like pseudo, but better. Since pseudo and fakeroot does not work with static binaries. (And this is what I thought Alex was looking into.) Cheers, Claudius --=20 DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153 Keyserver: hkp://pool.sks-keyservers.net --=-kLNwQNnCxfKZ/qqWUkho Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEb/LlnwDGvCgx2GTBEXPLGZgIsVMFAloIC/wACgkQEXPLGZgI sVMYJhAAh8MK5KuT6K+rrZgt8MtH0JETb3IucdDcmoF430Z/PVG/p9t1Vw2bSt1n uik2XLC/53CtRPLBWPEqHB1BXan9DyMmYO5a+ZICcop98+y0BKjKgYVCRCcQf88C nDHaRBXfFrIOwY6lDxbnl9lj5ucnPWgY3QsedgHu/K/NdH8VkW95JlrbJyXmOY0k T+L8jtnSAMY25CwceF6O9oFsMtquunmSR9yjXu/hMuRpuF787KE92IxMEe/kLtns EfgKSd9XaP14avfXicYe/RqDlTlSG/ZDRxuliEseGbDK5v7g7nZUWHwcr16yWbCW O81q/iwLsXLP418PFUrug/oHxsL8pT6Kr399dC1FXNwO5SDGWRLTNwZz16sZRwMy ++JPYIDY6iGcuUkX/scjZu4SPfQNt0NOgEttIKhTQ68DWViHIZRsYTdpXXNP/Fg4 5GluKnRuI2nr4dREpcidKAys1FPn0g3h69GgY+VRR9LMl0rue9kAHR9Ep744UsVe SxIMH+1NHE3em2RxjJY7p5LONfgiAgZHwOJR76bc9G0eGYGOjG/MLvRyEYrLKUkG AT9XAj4mfwoR5tUwXDOTHvnh09Kw9Up9RqiVUcZppeyrofCG40SUBlk3nWRhNxEw TpPltPC7wg/wFde/GMCmFrSgDEvv8qzbA+x6r1oozMjzHmYq9Yw= =yGXK -----END PGP SIGNATURE----- --=-kLNwQNnCxfKZ/qqWUkho--