[Fuego] [PATCH] ftc: process jenkins_enabled

[daniel.sangorrin at toshiba.co.jp]

> -----Original Message-----
> From: Tim.Bird at sony.com <Tim.Bird at sony.com>
> Sent: Tuesday, March 5, 2019 10:50 AM
> To: sangorrin daniel(サンゴリン ダニエル ○ＳＷＣ□ＯＳＴ) <daniel.sangorrin at toshiba.co.jp>;
> fuego at lists.linuxfoundation.org
> Subject: RE: [Fuego] [PATCH] ftc: process jenkins_enabled
> 
> > -----Original Message-----
> > From: daniel.sangorrin at toshiba.co.jp
> >
> > Hello Tim,
> >
> > > From: Tim.Bird at sony.com <Tim.Bird at sony.com>
> > > >  # if running as root, switch to jenkins
> > > >  # for now, use sudo, but could change to use direct setuid calls
> > > > -def user_check():
> > > > +def user_check(conf):
> > > > +    if not conf.jenkins_enabled:
> > > > +        return
> > > > +
> > > OK - this is quite dicey from a security standpoint.  We really shouldn't
> > > be running things as root, even if we're inside the Docker container.
> > > If ftc is running outside the Docker container, this is especially problematic.
> > >
> > > I'm going to put a FIXTHIS on this, but it worries me that we might forget
> > > and not come back to fix this up.  If we're not using Jenkins, it might be
> > worthwhile
> > > to define a 'fuego' user account (in the Docker container or on the host),
> > and
> > > switch to that in this routine, so that operations done in the context of a
> > test
> > > are not performed as the root account.
> > >
> > > This trusts the tests (which could be coming from a 3rd party or an
> > untrusted source)
> > > way too much.
> >
> > OK, I see your point but there are multiple use-cases that we need to
> > address.
> >
> > 1.- With Jenkins: here we definitely need to use the 'jenkins' user.
> > 2.- Without Jenkins and host-target configuration: the user should not (and
> > doesn't need) to run with root permissions
> >    - I will add a default user 'fuego' to Dockerfile.nojenkins, and make sure
> > that when users start a container the default user is 'fuego' and not 'root'.
> >    - There is nothing in this patch that prevents a user from running 'ftc' with
> > or without root-permissions. We could test for a "fuego" user, and switch
> > automatically to it in case it exists. However, that may cause conflicts with the
> > next use case. For that reason, I think that there is no need for adding a
> > fixthis at that place once the Dockerfile.nojenkins is fixed.
> > 3.- Without Jenkins and a host-only configuration: when you want to run
> > tests on your PC (host-only/native) then it really depends on what tests you
> > want to run. Tests with NEED_ROOT=1 will require you to have root
> > permissions when you run 'ftc'. In this case, the user must decide whether
> > using root-permissions (sudo) or not.
> >
> > What do you think?
> Upon further reflection, I believe the 'root' user in the docker
> container is running as the host user (the one who did the build and install of the
> container) on the host machine.  So there might not be that big of a security
> exposure, even if Fuego runs as root in the container.
> 
> However, I agree with all your points, and it sounds fine to me to create a 'fuego'
> account, and run as that.  This might be useful in the non-jenkins case as well,
> whether inside or outside the container.  That is, someone might want to run Fuego
> in a host-only/native environment as either:
>  * root
>  * fuego
>  * the host user
> for different levels of security or caution.  For example, someone might
> not want Fuego running things on their own account.  It opens the door
> to a malicious or accidental operation which could affect their personal data.
> 
> I'm not sure what the default should be.  I'm inclined, in the non-jenkins
> case, to run the code as the host user by default.  But that's not the safest option.
> Maybe, we should use the same logic - if a 'fuego' account exists, then switch to
> that.  Or maybe this needs a fuego.conf setting.
> 
> Thoughts?

I think that there is no difference between 'ftc' and any other command. Fuego users should be able to decide what permissions and what Linux user they want to use when calling ftc. I agree that for security reasons 'ftc' should not be called with root permissions in a host-target configuration. But enforcing that by automatically switching to another Linux user will confuse Fuego users. Maybe a warning message would be better.

$ ftc list-boards
$ sudo ftc list-boards
$ sudo runuser -u myuserchoice ftc list-boards

When using ftc in a native environment I am including the use case where Fuego is executed as part of a LAVA job on the target board. In other words, Fuego (without Jenkins) is installed in the board's image (eg: apt-get install fuego, in the future) and the job sent to LAVA will include a step like:
$ sudo ftc run-test -b local -t Functional.ltp --report-to-lava
 [Note] --report-to-lava is something that I will add soon, and just prints the run.json to stdout (which is read from the serial port in LAVA) in a format that LAVA understands (slides 4,5 at [1]). Something like this:
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=Benchmark.Dhrystone RESULT=pass MEASUREMENT=2342342>
[Note] What do you think about using "local" as the default board if -b is not supplied?

[1] https://events.linuxfoundation.org/wp-content/uploads/2017/12/Teaching-your-Test-Framework-to-Speak-LAVA-Tim-Orling-Intel-Corporation.pdf

To summarize:
- Dockerfile.nojenkins: add a 'fuego' user (the default when you start the container) but if the user decides to run ftc as root (sudo ftc run-test..) just show a warning ("WARNING: running Fuego as root can destroy your filesystem or worse") and do not automatically change the user.
- Native environment: a 'fuego' user will not exist, but do the same (output a warning message)

Thanks,
Daniel