Re: Isar fork

[Claudius Heine <claudius.heine.ext@siemens.com>]

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: ch@denx.de