From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6478179128234213376 Date: Wed, 18 Oct 2017 07:02:12 -0700 (PDT) From: Ben Brenson To: isar-users Message-Id: <74238db2-27cf-4cb3-b549-60da092134d3@googlegroups.com> In-Reply-To: <6b3eb259-b278-3b9d-c375-cca6cc0359a3@siemens.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> Subject: Re: Isar fork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_26924_27988747.1508335332416" X-Google-Token: EOS9nc8Fa-mD16MCGPk0 X-Google-IP: 178.27.65.121 X-TUID: G/y1+MUoL5pV ------=_Part_26924_27988747.1508335332416 Content-Type: multipart/alternative; boundary="----=_Part_26925_1238909979.1508335332417" ------=_Part_26925_1238909979.1508335332417 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah ok, 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 > > 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. Root privileges inside a Docker container are sadly not a good enough=20 > security mechanism, because you would have to grant the container the=20 > sys_admin capabilities for loop mount and now its able to potentially=20 > overwrite disk content or access the complete host memory.=20 > So the best solution would be to implement a non-root approach. Otherwise= =20 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? Regards, Benedikt 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=20 > 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= =20 > 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= =20 > users inside the new root path.=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 > > > 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= =20 > put itself between the running application and the kernel. While its a=20 > 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= =20 > >> 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= =20 > > exactly the same, like running it without schroot.=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=20 > sys_admin capabilities for loop mount and now its able to potentially=20 > overwrite disk content or access the complete host memory.=20 > > And since you might use layers from not completely trusted developers it= =20 > should be made reasonable secure.=20 > > Cheers,=20 > Claudius=20 > > --=20 > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk=20 > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany=20 > Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de= =20 > =20 > ------=_Part_26925_1238909979.1508335332417 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ah ok,

I am not sure about it, but when I installed it, this popped = up:

=C2=A0 =C2=A0 =C2=A0Setting up schroot (1.6.10-4) ...
=C2=A0 =C2=A0 =C2=A0Created symlink=20
/etc/systemd/system/multi-
user.t= arget.wants/schroot.service =E2=86=92=20
/lib/systemd/system/schroot.service.
Indeed a service will be installed, but thats only a one-shot which is exec= uted once after boot. It performs some steps on "/var/lock/schroot&quo= t;.
So there is no daemon running in the background.

Root privileges inside a Dock= er container are sadly not a good enough=20
security mechanism, because you would have to grant the container the= =20
sys_admin capabilities for loop mount and now its able to potentially= =20
overwrite disk content or access the complete host memory.

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.
A time ago I tried to setup de= bootstrap by using fakechroot, but that wasn't staight forward to solve= .
Maybe with multistrap, things would be much easier here?


Re= gards,
Benedikt




Am Mittwoch, 18. Oktober 2017 14:52:4= 7 UTC+2 schrieb Claudius Heine:
Hi,

On 10/18/2017 02:11 PM, 'Ben Brenson' via isar-users wrote:
> Hi Claudius,
>=20
> I see that you are using schroot. How is your progress on 'sud= o' removal?
>>
> =C2=A0=20
> schroot itself, doesn't solve the 'sudo' problem, but = it's very useful for
> running common tasks when setting up a chroot, like mounting files= ystems,
> setting up binfmt etc.
> So basically it extends the chroot command itself.

I don't now much about schroot, just assumed some stuff when quickl= y=20
investigating it.

=C2=A0From the manpage:

=C2=A0 =C2=A0A chroot may be used directly as root by running chroot(8)= , but=20
normal users =C2=A0are
=C2=A0 =C2=A0not =C2=A0able to use this command. =C2=A0schroot allows a= ccess to chroots for=20
normal users
=C2=A0 =C2=A0using the same mechanism, but with several additional =C2= =A0features.

=C2=A0From that I assumed that it takes care about normal users getting= root=20
users inside the new root path.

>=20
> I haven't heard of schroot before, but from what I gather it n= eeds a
>> privileged service to run in the background.
>>
> =C2=A0=20
> I've never heard about or noticed that schroot needs a =C2=A0p= rivileged service
> running in the background. Maybe I have to check this.

I am not sure about it, but when I installed it, this popped up:

=C2=A0 =C2=A0 =C2=A0Setting up schroot (1.6.10-4) ...
=C2=A0 =C2=A0 =C2=A0Created symlink=20
/etc/systemd/system/multi-user.target.wants/schroot.service = =E2=86=92=20
/lib/systemd/system/schroot.service.

So I assumed is uses this service for privileged stuff.

> The main cause for introducing the schroot feature, was to have a = already
> implemented framework, when setting up chroots (mostly related to = setting
> up mounts).
> Since a lot of chroot tasks running in parallel, if searched for a= reliable
> chroot extension.

I only had some experience using proot which uses the ptrace syscall to= =20
put itself between the running application and the kernel. While its a= =20
pretty nice an isolated solutions, it also has some downsides to it.

>=20
> What are your experience with it? Could it be used for all parts t= hat
>> currently require root privileges? Have you tried it inside a = docker
>> container?
>>
>=20
> That is what I think the docker container is for solving the '= sudo' problem.
> Running schroot inside a docker container is now problems and beha= ves
> exactly the same, like running it without schroot.

Root privileges inside a Docker container are sadly not a good enough= =20
security mechanism, because you would have to grant the container the= =20
sys_admin capabilities for loop mount and now its able to potentially= =20
overwrite disk content or access the complete host memory.

And since you might use layers from not completely trusted developers i= t=20
should be made reasonable secure.

Cheers,
Claudius

--=20
DENX Software Engineering GmbH, =C2=A0 =C2=A0 =C2=A0Managing 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
------=_Part_26925_1238909979.1508335332417-- ------=_Part_26924_27988747.1508335332416--