Re: Isar fork

[Ben Brenson <benbrenson89@googlemail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4389 bytes --]

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. 
>

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?


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:> 
>

[-- Attachment #1.2: Type: text/html, Size: 5415 bytes --]