Re: Isar fork

[Henning Schild <henning.schild@siemens.com>]

On Wed, 18 Oct 2017 07:02:12 -0700
'Ben Brenson' via isar-users <isar-users@googlegroups.com> wrote:

> Ah ok,
> 
> I am not sure about it, but when I installed it, this popped up: 
> >
> >      Setting up schroot (1.6.10-4) ... 
> >      Created symlink 
> > /etc/systemd/system/multi-  
> >>
> >> user.target.wants/schroot.service → 
> >> /lib/systemd/system/schroot.service.   
> >
> > Indeed a service will be installed, but thats only a one-shot which
> > is   
> 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 
> > 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. 

That top-posting messed up citation. Please avoid top-posting.
 
> 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 debootstrap by using fakechroot, but that 
> 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

> 
> Regards,
> Benedikt
> 
> 
> 
> 
> Am Mittwoch, 18. Oktober 2017 14:52:47 UTC+2 schrieb Claudius Heine:
> >
> > Hi, 
> >
> > On 10/18/2017 02:11 PM, 'Ben Brenson' via isar-users wrote:   
> > > Hi Claudius, 
> > > 
> > > I see that you are using schroot. How is your progress on
> > > 'sudo'   
> > removal?   
> > >>   
> > >   
> > > schroot itself, doesn't solve the 'sudo' problem, but it's very
> > > useful   
> > for   
> > > running common tasks when setting up a chroot, like mounting   
> > filesystems,   
> > > setting up binfmt etc. 
> > > So basically it extends the chroot command itself.   
> >
> > I don't now much about schroot, just assumed some stuff when
> > quickly investigating it. 
> >
> >  From the manpage: 
> >
> >    A chroot may be used directly as root by running chroot(8), but 
> > normal users  are 
> >    not  able to use this command.  schroot allows access to chroots
> > for normal users 
> >    using the same mechanism, but with several additional  features. 
> >
> >  From that I assumed that it takes care about normal users getting
> > root users inside the new root path. 
> >  
> > > 
> > > I haven't heard of schroot before, but from what I gather it
> > > needs a   
> > >> privileged service to run in the background. 
> > >>   
> > >   
> > > I've never heard about or noticed that schroot needs a
> > > privileged   
> > 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: 
> >
> >      Setting up schroot (1.6.10-4) ... 
> >      Created symlink 
> > /etc/systemd/system/multi-user.target.wants/schroot.service → 
> > /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 put itself between the running application and the
> > kernel. While its a pretty nice an isolated solutions, it also has
> > some downsides to it. 
> > > 
> > > What are your experience with it? Could it be used for all parts
> > > that   
> > >> currently require root privileges? Have you tried it inside a
> > >> docker container? 
> > >>   
> > > 
> > > That is what I think the docker container is for solving the
> > > 'sudo'   
> > problem.   
> > > Running schroot inside a docker container is now problems and
> > > behaves exactly the same, like running it without schroot.   
> >
> > 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. 
> >
> > And since you might use layers from not completely trusted
> > developers it should be made reasonable secure. 
> >
> > Cheers, 
> > Claudius 
> >
> > -- 
> > 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 <javascript:> 
> >  
>