how to *securely* do a remote install of an OE image?

how to *securely* do a remote install of an OE image?

[Robert P. J. Day]

  here's a puzzler someone just presented me with ... given an
established OE build, and a way to download and install it to a remote
system, how would one set up root and/or non-root accounts and
passwords to then allow an *authorized* someone to log in to the
newly-installed system and configure it?

  as in, if the installed image contains a "root" account and default
password, there is the potential of someone sneaking in there in the
interval between installation and when the "authorized" user connects
to do the configuration, even if the first act of the authorized user
is to change the root password.

  my immediate reaction was to use SSH keys, where the
newly-installed system would require SSH logins, and would have to
match the corresponding private key.

  as an alternative, perhaps don't worry about such a situation, but
when the authorized user logs in for what is *supposed* to be the
first time, it will be flagged that someone else has already logged in
earlier, and a warning will be printed, "Previous login to root
detected, you have been compromised, please re-install!"

  i'm sure there are plenty of ways of doing this, anyone have any
pointers? thanks.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: how to *securely* do a remote install of an OE image?

[Patrick Ohly]

On Tue, 2017-02-28 at 05:28 -0500, Robert P. J. Day wrote:
>   my immediate reaction was to use SSH keys, where the
> newly-installed system would require SSH logins, and would have to
> match the corresponding private key.

That would also be my preferred approach.

>   as an alternative, perhaps don't worry about such a situation, but
> when the authorized user logs in for what is *supposed* to be the
> first time, it will be flagged that someone else has already logged in
> earlier, and a warning will be printed, "Previous login to root
> detected, you have been compromised, please re-install!"

Or, along the same lines, set an empty root password and force the user
to set a password on the first login. There are ways to do that with
PAM, but I don't have anything at hand.

>   i'm sure there are plenty of ways of doing this, anyone have any
> pointers?

For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:

INHERIT += "rootfsdebugfiles"
ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"

This copies my id_rsa.pub into authorized_keys and thus let's me log
into images that I create via ssh.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: how to *securely* do a remote install of an OE image?

[Gary Thomas]

On 2017-02-28 13:27, Patrick Ohly wrote:
> On Tue, 2017-02-28 at 05:28 -0500, Robert P. J. Day wrote:
>>   my immediate reaction was to use SSH keys, where the
>> newly-installed system would require SSH logins, and would have to
>> match the corresponding private key.
>
> That would also be my preferred approach.
>
>>   as an alternative, perhaps don't worry about such a situation, but
>> when the authorized user logs in for what is *supposed* to be the
>> first time, it will be flagged that someone else has already logged in
>> earlier, and a warning will be printed, "Previous login to root
>> detected, you have been compromised, please re-install!"
>
> Or, along the same lines, set an empty root password and force the user
> to set a password on the first login. There are ways to do that with
> PAM, but I don't have anything at hand.
>
>>   i'm sure there are plenty of ways of doing this, anyone have any
>> pointers?
>
> For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
>
> INHERIT += "rootfsdebugfiles"
> ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
>
> This copies my id_rsa.pub into authorized_keys and thus let's me log
> into images that I create via ssh.
>

Does this work for dropbear or only openssh?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: how to *securely* do a remote install of an OE image?

[Patrick Ohly]

On Tue, 2017-02-28 at 13:32 +0100, Gary Thomas wrote:
> > For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
> >
> > INHERIT += "rootfsdebugfiles"
> > ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub
> ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
> >
> > This copies my id_rsa.pub into authorized_keys and thus let's me log
> > into images that I create via ssh.
> >
> 
> Does this work for dropbear or only openssh?

Should also work with dropbear. From
https://matt.ucc.asn.au/dropbear/dropbear.html:

"Compatible with OpenSSH ~/.ssh/authorized_keys public key
authentication"

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: how to *securely* do a remote install of an OE image?

[Robert P. J. Day]

On Tue, 28 Feb 2017, Patrick Ohly wrote:

> For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
>
> INHERIT += "rootfsdebugfiles"
> ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
>
> This copies my id_rsa.pub into authorized_keys and thus let's me log
> into images that I create via ssh.

  this has definite potential, but i'm about to check whether the
person/entity that builds the image vs. the person/entity that does
the install vs. the person that eventually logs into the new system to
finish setting up could potentially be different.

  there's a *possibility* that remote installation might be done by a
distributor, after which someone else might need to do the first
login to finish the setup, which would complicate things immensely.

  i don't know that this is what will happen, but i'm about to run off
and ask about possibilities.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: how to *securely* do a remote install of an OE image?

[Bryan Evenson]

Robert,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of Robert P. J. Day
> Sent: Tuesday, February 28, 2017 10:20 AM
> To: Patrick Ohly <patrick.ohly@intel.com>
> Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] how to *securely* do a remote install of an OE image?
> 
> On Tue, 28 Feb 2017, Patrick Ohly wrote:
> 
> > For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
> >
> > INHERIT += "rootfsdebugfiles"
> > ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub
> ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
> >
> > This copies my id_rsa.pub into authorized_keys and thus let's me log
> > into images that I create via ssh.
> 
>   this has definite potential, but i'm about to check whether the
> person/entity that builds the image vs. the person/entity that does the
> install vs. the person that eventually logs into the new system to finish
> setting up could potentially be different.
> 
>   there's a *possibility* that remote installation might be done by a
> distributor, after which someone else might need to do the first login to
> finish the setup, which would complicate things immensely.

Are you talking about burning the initial image or firmware upgrade?  If you're talking about firmware upgrade, another possibility is that you could flip the direction of access.  Instead of remotely logging into each target system, have the target systems remotely login to a centralized server.  That's the approach we took.  We burn the systems with the latest image, and then when we assign them a serial number the system is given a set of SSH keys specific to that serial number.  That set of SSH keys is then used to access the centralized server and obtain the latest firmware.  With this method there's no need to login to the target system, so you can lock it down as much as you want.

Regards,
Bryan

> 
>   i don't know that this is what will happen, but i'm about to run off and ask
> about possibilities.
> 
> rday
> 
> --
> 
> ==========================================================
> ==============
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ==========================================================
> ==============
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: how to *securely* do a remote install of an OE image?

[Enrico Scholz]

"Robert P. J. Day" <rpjday-L09J2beyid0N/H6P543EQg@public.gmane.org>
writes:

>   here's a puzzler someone just presented me with ... given an
> established OE build, and a way to download and install it to a
> remote system, how would one set up root and/or non-root accounts
> and passwords to then allow an *authorized* someone to log in to the
> newly-installed system and configure it?
>
>   as in, if the installed image contains a "root" account and default
> password, there is the potential of someone sneaking in there in the
> interval between installation and when the "authorized" user connects
> to do the configuration, even if the first act of the authorized user
> is to change the root password.

I do not think that this can be prevented.  When an attacker gains root
access, he can do everything with the system.  E.g. he can replace your
intrusion detection system with a custom one which does not report his
login.

You could use hardware features like burning fuses, or erasing keys in
TPM chips or increasing login counters there.  But again, an attacker
can alter the underlying login mechanism to report an untouched system.

So, you should try to prevent that an attacker can login to the systsem.


>   my immediate reaction was to use SSH keys, where the
> newly-installed system would require SSH logins, and would have to
> match the corresponding private key.

Yes; public key authentication is the way to go... You will never get
the system secure with a static default root password.

For SSH keys we are using [1] for ages.

OpenSSH supports CA keys[2]; e.g. you do not need to add every allowed
pubkey to 'authorized_keys' but only a CA pubkey.  This CA signs user
keys which are allowed to login.

Alternatively, you can implement something which sets the default
root password based on some serial number of the device.  But this is
difficultly to implement and brute force attacks might be very simple
(serial numbers are usually predictable).

Or, you can implement an OTP mechanism based on DSS or so.  E.g. device
contains a public key and presents a random number at login.  You have
to sign it with the corresponding secret key and enter it as a password.

 


Enrico

Footnotes: 
[1]  https://github.com/sigma-embedded/elito-de.sigma-chemnitz/blob/master/meta/classes/elito-image.bbclass#L56

[2]  https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

-- 
SIGMA Chemnitz GmbH       Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13           Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz