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