From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6478179128234213376 X-Received: by 10.80.152.61 with SMTP id g58mr4222043edb.5.1508336385273; Wed, 18 Oct 2017 07:19:45 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.219.194 with SMTP id s2ls1896265edk.5.gmail; Wed, 18 Oct 2017 07:19:45 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAsq2R/+x03C23J8qykT8yrj7FfXsTZoIpMczotwWD54mLZcPezUZaL/LrIo9xKiiuIdAMu X-Received: by 10.80.206.3 with SMTP id y3mr4225460edi.11.1508336385013; Wed, 18 Oct 2017 07:19:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508336384; cv=none; d=google.com; s=arc-20160816; b=rv2yD9QhWRFXcLeKM/1ZTbemqT0vekI8Nmc+a/beVxB4r93ZfQrPVsyWQtNUsDj32R 1SqYTY63GX+YFluF89l/UheUbTD0Ff1i/ar/Tl14uf0S9+kYo/ppVr53dHlMEghFbkSS JjKtO15AnlUnGXSU7wCxmVfwleGdqew/DJaDIMm+PuuDWvK1SxUYexG/CxFFVtdllszL MHCa2XHhBre7K1a8Lwi1OlzEqcLwh+GPoB/E+jJiBSzsEPXI6LilhuFMhfR7CYyBSYg+ 02SsOKviJLcm39MwxL9Wnrw3H4HvAD49l7LwAzDr04KnHU8jrxeRXwKsQmNOLLUZ94fE RUNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=31Ep8XSoQT5UcGlaUOI9woqp6F90+Px7+UaEOGiW3Gg=; b=00K5cW/55PHZbbWoPXjD+GIU9uB4z8FlN3o+L3RDqunf4YFnXjllHmvF1scUEmBjVK KfNvrmI/915VydQU7VpjLgEg+n7g4+mv2p8CN5Q6k6KnwwQJo8SGLdLJmBRGZZ5n0qv3 mrfOnTAd1mLiQ8sPWHeB6is67+G+emEQVQDJylw0icvLZpG2An7pQOkxqOueXGVI2eVl xzmdagrzb9GnF7EBAoVePyAFV3qPTovW2tM18sT54YVXE5RGvePPjuhFmdY34eDgSv+s /6FKO1XVyH6/JMiQNJk8euh29ZcFxbvqzqHdCxL8B+yg/L9bhG2Ep1Hfpg/RfsFLisv+ 0rCQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id h23si701822ede.4.2017.10.18.07.19.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 07:19:44 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v9IEJikM030427 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 18 Oct 2017 16:19:44 +0200 Received: from md1em3qc ([139.25.68.40]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v9IEJiMV012299; Wed, 18 Oct 2017 16:19:44 +0200 Date: Wed, 18 Oct 2017 16:19:43 +0200 From: Henning Schild To: "'Ben Brenson' via isar-users" Cc: isar-users Subject: Re: Isar fork Message-ID: <20171018161943.48e87ca4@md1em3qc> In-Reply-To: <74238db2-27cf-4cb3-b549-60da092134d3@googlegroups.com> References: <8fe13268-9bfa-4b24-897a-133c9530c188@googlegroups.com> <3ad4ed89-de76-9a07-c2f5-3abea0583f68@siemens.com> <0eeda167-efa1-4eaf-ade5-8d43d09f2c8a@googlegroups.com> <6b3eb259-b278-3b9d-c375-cca6cc0359a3@siemens.com> <74238db2-27cf-4cb3-b549-60da092134d3@googlegroups.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: gbDdunigGqK/ On Wed, 18 Oct 2017 07:02:12 -0700 'Ben Brenson' via isar-users wrote: > Ah ok, >=20 > I am not sure about it, but when I installed it, this popped up:=20 > > > > Setting up schroot (1.6.10-4) ...=20 > > Created symlink=20 > > /etc/systemd/system/multi- =20 > >> > >> user.target.wants/schroot.service =E2=86=92=20 > >> /lib/systemd/system/schroot.service. =20 > > > > Indeed a service will be installed, but thats only a one-shot which > > is =20 > executed once after boot. It performs some steps on > "/var/lock/schroot". So there is no daemon running in the background. >=20 > Root privileges inside a Docker container are sadly not a good enough=20 > > security mechanism, because you would have to grant the container > > the sys_admin capabilities for loop mount and now its able to > > potentially overwrite disk content or access the complete host > > memory.=20 That top-posting messed up citation. Please avoid top-posting. =20 > So the best solution would be to implement a non-root approach. > Otherwise there will always persist some security issues. > For now I don't have any solutions, yet.=20 > A time ago I tried to setup debootstrap by using fakechroot, but that=20 > wasn't staight forward to solve. > Maybe with multistrap, things would be much easier here? I think the answer is simple, use a VM instead of docker and stop looking for a solution. All the attempts to work around the sudo-problem have serious limitations. And all but libpseudo seem to be dying and unmaintained, because containers and VMs are around and nobody cares. Henning >=20 > Regards, > Benedikt >=20 >=20 >=20 >=20 > Am Mittwoch, 18. Oktober 2017 14:52:47 UTC+2 schrieb Claudius Heine: > > > > Hi,=20 > > > > On 10/18/2017 02:11 PM, 'Ben Brenson' via isar-users wrote: =20 > > > Hi Claudius,=20 > > >=20 > > > I see that you are using schroot. How is your progress on > > > 'sudo' =20 > > removal? =20 > > >> =20 > > > =20 > > > schroot itself, doesn't solve the 'sudo' problem, but it's very > > > useful =20 > > for =20 > > > running common tasks when setting up a chroot, like mounting =20 > > filesystems, =20 > > > setting up binfmt etc.=20 > > > So basically it extends the chroot command itself. =20 > > > > I don't now much about schroot, just assumed some stuff when > > quickly investigating it.=20 > > > > From the manpage:=20 > > > > A chroot may be used directly as root by running chroot(8), but=20 > > normal users are=20 > > not able to use this command. schroot allows access to chroots > > for normal users=20 > > using the same mechanism, but with several additional features.=20 > > > > From that I assumed that it takes care about normal users getting > > root users inside the new root path.=20 > > =20 > > >=20 > > > I haven't heard of schroot before, but from what I gather it > > > needs a =20 > > >> privileged service to run in the background.=20 > > >> =20 > > > =20 > > > I've never heard about or noticed that schroot needs a > > > privileged =20 > > service =20 > > > running in the background. Maybe I have to check this. =20 > > > > I am not sure about it, but when I installed it, this popped up:=20 > > > > Setting up schroot (1.6.10-4) ...=20 > > Created symlink=20 > > /etc/systemd/system/multi-user.target.wants/schroot.service =E2=86=92=20 > > /lib/systemd/system/schroot.service.=20 > > > > So I assumed is uses this service for privileged stuff.=20 > > =20 > > > The main cause for introducing the schroot feature, was to have > > > a =20 > > already =20 > > > implemented framework, when setting up chroots (mostly related > > > to =20 > > setting =20 > > > up mounts).=20 > > > Since a lot of chroot tasks running in parallel, if searched for > > > a =20 > > reliable =20 > > > chroot extension. =20 > > > > I only had some experience using proot which uses the ptrace > > syscall to put itself between the running application and the > > kernel. While its a pretty nice an isolated solutions, it also has > > some downsides to it.=20 > > >=20 > > > What are your experience with it? Could it be used for all parts > > > that =20 > > >> currently require root privileges? Have you tried it inside a > > >> docker container?=20 > > >> =20 > > >=20 > > > That is what I think the docker container is for solving the > > > 'sudo' =20 > > problem. =20 > > > Running schroot inside a docker container is now problems and > > > behaves exactly the same, like running it without schroot. =20 > > > > Root privileges inside a Docker container are sadly not a good > > enough security mechanism, because you would have to grant the > > container the sys_admin capabilities for loop mount and now its > > able to potentially overwrite disk content or access the complete > > host memory.=20 > > > > And since you might use layers from not completely trusted > > developers it should be made reasonable secure.=20 > > > > Cheers,=20 > > Claudius=20 > > > > --=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: > > c...@denx.de =20 > > =20 >=20