Configure command shell idle timeout default?


Joseph Reynolds
 

Yocto security community,

Is Yocto interested in configuring a "SSH command shell session idle timeout" to a more secure default?


Standards:

I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout. https://github.com/openbmc/bmcweb/blob/master/include/sessions.hpp timeoutInSeconds

- NIST SP800-63B requires a timeout of 30 minutes for "assurance level 2" (high confidence that the authentication is still valid), or 15 minutes for "assurance level 2" (very high confidence). https://pages.nist.gov/800-63-3/sp800-63b.html
- OWASP suggests idle timeouts of 15-30 minutes. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration



Technical implementation:

I understand the timeout can be implemented either in the SSH session or in the underlying application:

The bash shell offers the TMOUT variable for auto-logout to set the session's idle timeout.  (This can be set to readonly before the shell user gets control so they cannot change the timeout behavior.)

The OpenSSH server has removed the idle-timeout controls and recommends doing it via the underlying application.

The dropbear SSH server can configure the per-session idle timeout in one of two ways:
1. At compile time per https://github.com/mkj/dropbear/blob/master/default_options.h preprocessor symbol DEFAULT_IDLE_TIMEOUT.
2. When the server starts via argument `-I 0`, and note SSH server started by: https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service where shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).


Discussion:

I understand Yocto's current default (no timeout, meaning the SSH and shell session stay open forever) may be correct for some users, but I believe the OpenBMC project (downstream from Yocto) will want a more secure default.  I would be happy with either keeping the current (insecure) defaults, or with changing the default as I recommended above, and seek to settle this question.

I've added this question to the OpenBMC security working group agenda.  Next meeting Wednesday August 4.  Access via https://github.com/openbmc/openbmc/wiki/Security-working-group

- Joseph


Richard Purdie
 

On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:
Yocto security community,

Is Yocto interested in configuring a "SSH command shell session idle
timeout" to a more secure default?


Standards:

I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout.
https://github.com/openbmc/bmcweb/blob/master/include/sessions.hpp timeoutInSeconds

- NIST SP800-63B requires a timeout of 30 minutes for "assurance level
2" (high confidence that the authentication is still valid), or 15
minutes for "assurance level 2" (very high confidence).
https://pages.nist.gov/800-63-3/sp800-63b.html
- OWASP suggests idle timeouts of 15-30 minutes.
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration



Technical implementation:

I understand the timeout can be implemented either in the SSH session or
in the underlying application:

The bash shell offers the TMOUT variable for auto-logout to set the
session's idle timeout.  (This can be set to readonly before the shell
user gets control so they cannot change the timeout behavior.)

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.

The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per
https://github.com/mkj/dropbear/blob/master/default_options.h preprocessor
symbol DEFAULT_IDLE_TIMEOUT.
2. When the server starts via argument `-I 0`, and note SSH server
started by:
https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service where
shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).


Discussion:

I understand Yocto's current default (no timeout, meaning the SSH and
shell session stay open forever) may be correct for some users, but I
believe the OpenBMC project (downstream from Yocto) will want a more
secure default.  I would be happy with either keeping the current
(insecure) defaults, or with changing the default as I recommended
above, and seek to settle this question.

I've added this question to the OpenBMC security working group agenda. 
Next meeting Wednesday August 4.  Access via
https://github.com/openbmc/openbmc/wiki/Security-working-group

I think what I'd like to see from the Yocto Project perspective is to document
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).

I know you mentioned some work related to changing passwords too and trying
to get that documented with YP is still on my radar, I just don't have time
to do everything I'd like. Help with that would be much appreciated!

Cheers,

Richard


Joseph Reynolds
 

On 8/3/21 9:44 AM, Richard Purdie wrote:
On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:
Yocto security community,

Is Yocto interested in configuring a "SSH command shell session idle
timeout" to a more secure default?


Standards:

I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout.
https://github.com/openbmc/bmcweb/blob/master/include/sessions.hpp timeoutInSeconds

- NIST SP800-63B requires a timeout of 30 minutes for "assurance level
2" (high confidence that the authentication is still valid), or 15
minutes for "assurance level 2" (very high confidence).
https://pages.nist.gov/800-63-3/sp800-63b.html
- OWASP suggests idle timeouts of 15-30 minutes.
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration



Technical implementation:

I understand the timeout can be implemented either in the SSH session or
in the underlying application:

The bash shell offers the TMOUT variable for auto-logout to set the
session's idle timeout.  (This can be set to readonly before the shell
user gets control so they cannot change the timeout behavior.)

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.

The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per
https://github.com/mkj/dropbear/blob/master/default_options.h preprocessor
symbol DEFAULT_IDLE_TIMEOUT.
2. When the server starts via argument `-I 0`, and note SSH server
started by:
https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service where
shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).


Discussion:

I understand Yocto's current default (no timeout, meaning the SSH and
shell session stay open forever) may be correct for some users, but I
believe the OpenBMC project (downstream from Yocto) will want a more
secure default.  I would be happy with either keeping the current
(insecure) defaults, or with changing the default as I recommended
above, and seek to settle this question.

I've added this question to the OpenBMC security working group agenda.
Next meeting Wednesday August 4.  Access via
https://github.com/openbmc/openbmc/wiki/Security-working-group
I think what I'd like to see from the Yocto Project perspective is to document
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).

I know you mentioned some work related to changing passwords too and trying
to get that documented with YP is still on my radar, I just don't have time
to do everything I'd like. Help with that would be much appreciated!
Mea culpa!  I have a two unresolved issues:
- Proposal to write an "initial/administratively expired password" into /etc/shadow - https://github.com/openembedded/openembedded-core/pull/63
- Proposal to fixup libpwquality.bb PACKAGECONFIG to avoid pulling in Python3 - https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/41357/2/meta-openembedded/meta-oe/recipes-extended/libpwquality/libpwquality_1.4.4.bb

I believe the proposals are well defined and coded up.  My inhibitors are finding time and rounding out my skillset.  Maybe I can find a minion to do these for me.  :-)

- Joseph


Cheers,

Richard



Mark Hatle
 

On 8/3/21 9:44 AM, Richard Purdie wrote:
On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:
Yocto security community,

Is Yocto interested in configuring a "SSH command shell session idle
timeout" to a more secure default?


Standards:

I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout.
https://github.com/openbmc/bmcweb/blob/master/include/sessions.hpp timeoutInSeconds

- NIST SP800-63B requires a timeout of 30 minutes for "assurance level
2" (high confidence that the authentication is still valid), or 15
minutes for "assurance level 2" (very high confidence).
https://pages.nist.gov/800-63-3/sp800-63b.html
- OWASP suggests idle timeouts of 15-30 minutes.
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration
To me the above means that you must have a way to do this, and it must be
configured as such... The Yocto Project doesn't care as much about the 'must be
configured as much', but definitely we should care about the 'you CAN configure
it as such, without impacting users who don't want a timeout.'


Technical implementation:

I understand the timeout can be implemented either in the SSH session or
in the underlying application:

The bash shell offers the TMOUT variable for auto-logout to set the
session's idle timeout.  (This can be set to readonly before the shell
user gets control so they cannot change the timeout behavior.)
It's my understanding that this is typically done via PAM and standard
.bashrc/.profiles.

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.
In the past, when I've worked on this stuff, we did timeout stuff in a
combination of 'screen', and ssh settings. Login would run through screen with
a timeout defined.

Screen could be set with a specific idle that required credentials, and then
bash (or other shells) would be set with a specific timeout as well. This would
ensure that the screen locks after a specific amount of time, such as 15
minutes. And the shell (Assuming it's back) will actually exit after a specific
timeout.

The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per
https://github.com/mkj/dropbear/blob/master/default_options.h preprocessor
symbol DEFAULT_IDLE_TIMEOUT.
2. When the server starts via argument `-I 0`, and note SSH server
started by:
https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service where
shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).


Discussion:

I understand Yocto's current default (no timeout, meaning the SSH and
shell session stay open forever) may be correct for some users, but I
believe the OpenBMC project (downstream from Yocto) will want a more
secure default.  I would be happy with either keeping the current
(insecure) defaults, or with changing the default as I recommended
above, and seek to settle this question.
This is the key, the default should continue to be no timeout. HOWEVER, as
Richard mentions below, there needs to be a documented approach for specifying
the timeouts. My opinion is that these should be configurable via root owned
configuration files to ensure settings can't be "changed" without appropriate
permissions.

I've added this question to the OpenBMC security working group agenda. 
Next meeting Wednesday August 4.  Access via
https://github.com/openbmc/openbmc/wiki/Security-working-group

I think what I'd like to see from the Yocto Project perspective is to document
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).
Agreed, I'm certainly interested in that.

I know you mentioned some work related to changing passwords too and trying
to get that documented with YP is still on my radar, I just don't have time
to do everything I'd like. Help with that would be much appreciated!
For my own products, I need to ensure that root logins are NOT allowed, no
default passwords are present and on first _CONSOLE_ login, the user to prompted
to set a password. (We do set a default user account, that has been given sudo
access.) Remote login's are not allowed until that has been done. (This is
already implemented and actually easy to accomplish. If there is additional
document requested about how to do this, let me know and I can share the steps
we do for the docs.)

--Mark

Cheers,

Richard







Mark Hatle
 

On 8/3/21 10:05 AM, Joseph Reynolds wrote:
On 8/3/21 9:44 AM, Richard Purdie wrote:
On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:
Yocto security community,

Is Yocto interested in configuring a "SSH command shell session idle
timeout" to a more secure default?


Standards:

I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout.
https://github.com/openbmc/bmcweb/blob/master/include/sessions.hpp timeoutInSeconds

- NIST SP800-63B requires a timeout of 30 minutes for "assurance level
2" (high confidence that the authentication is still valid), or 15
minutes for "assurance level 2" (very high confidence).
https://pages.nist.gov/800-63-3/sp800-63b.html
- OWASP suggests idle timeouts of 15-30 minutes.
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration



Technical implementation:

I understand the timeout can be implemented either in the SSH session or
in the underlying application:

The bash shell offers the TMOUT variable for auto-logout to set the
session's idle timeout.  (This can be set to readonly before the shell
user gets control so they cannot change the timeout behavior.)

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.

The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per
https://github.com/mkj/dropbear/blob/master/default_options.h preprocessor
symbol DEFAULT_IDLE_TIMEOUT.
2. When the server starts via argument `-I 0`, and note SSH server
started by:
https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service where
shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).


Discussion:

I understand Yocto's current default (no timeout, meaning the SSH and
shell session stay open forever) may be correct for some users, but I
believe the OpenBMC project (downstream from Yocto) will want a more
secure default.  I would be happy with either keeping the current
(insecure) defaults, or with changing the default as I recommended
above, and seek to settle this question.

I've added this question to the OpenBMC security working group agenda.
Next meeting Wednesday August 4.  Access via
https://github.com/openbmc/openbmc/wiki/Security-working-group
I think what I'd like to see from the Yocto Project perspective is to document
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).

I know you mentioned some work related to changing passwords too and trying
to get that documented with YP is still on my radar, I just don't have time
to do everything I'd like. Help with that would be much appreciated!
Mea culpa!  I have a two unresolved issues:
- Proposal to write an "initial/administratively expired password" into
/etc/shadow - https://github.com/openembedded/openembedded-core/pull/63
Password expire is already merged:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/extrausers.bbclass

See:

commit 834ef343b3694ccc4d44999771d49fb316f242e0
Author: Joseph Reynolds <joseph-reynolds@...>
Date: Tue Nov 10 11:56:42 2020 +0800

add new extrausers command passwd-expire

This enhances extrausers with a new passwd-expire command that causes
a local user's password to be expired as if the `passwd --expire`
command was run, so the password needs to be changed on initial login.

Example: EXTRA_USERS_PARAMS += " useradd ... USER; passwd-expire USER;"

Tested: on useradd accounts
When configured with Linux-PAM, console login prompts for and can
successfully change the password. OpenSSH server works. Dropbear
SSH server notes the password must be changed but does not offer a
password change dialog and rejects the login request.

(From OE-Core rev: 1bdcfa4b0d378947a6759fb91872a4edc9a42622)

Signed-off-by: Joseph Reynolds <joseph-reynolds@...>
Signed-off-by: Kai Kang <kai.kang@...>
Signed-off-by: Richard Purdie <richard.purdie@...>

We use this in our stuff to expire the user's password already.

- Proposal to fixup libpwquality.bb PACKAGECONFIG to avoid pulling in
Python3 -
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/41357/2/meta-openembedded/meta-oe/recipes-extended/libpwquality/libpwquality_1.4.4.bb

I believe the proposals are well defined and coded up.  My inhibitors
are finding time and rounding out my skillset.  Maybe I can find a
minion to do these for me.  :-)

- Joseph


Cheers,

Richard






Joseph Reynolds
 

On 8/3/21 1:54 PM, Mark Hatle wrote:

On 8/3/21 9:44 AM, Richard Purdie wrote:
On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:
Yocto security community,

Is Yocto interested in configuring a "SSH command shell session idle
timeout" to a more secure default?


Standards:

I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout.
https://github.com/openbmc/bmcweb/blob/master/include/sessions.hpp timeoutInSeconds

- NIST SP800-63B requires a timeout of 30 minutes for "assurance level
2" (high confidence that the authentication is still valid), or 15
minutes for "assurance level 2" (very high confidence).
https://pages.nist.gov/800-63-3/sp800-63b.html
- OWASP suggests idle timeouts of 15-30 minutes.
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration
To me the above means that you must have a way to do this, and it must be
configured as such... The Yocto Project doesn't care as much about the 'must be
configured as much', but definitely we should care about the 'you CAN configure
it as such, without impacting users who don't want a timeout.'
Thanks.  I understand and accept that Yocto will continue without any SSH or shell session idle timeouts.
I will pursue this configuration change for my downstream project (OpenBMC).

Technical implementation:

I understand the timeout can be implemented either in the SSH session or
in the underlying application:

The bash shell offers the TMOUT variable for auto-logout to set the
session's idle timeout.  (This can be set to readonly before the shell
user gets control so they cannot change the timeout behavior.)
It's my understanding that this is typically done via PAM and standard
.bashrc/.profiles.

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.
In the past, when I've worked on this stuff, we did timeout stuff in a
combination of 'screen', and ssh settings. Login would run through screen with
a timeout defined.

Screen could be set with a specific idle that required credentials, and then
bash (or other shells) would be set with a specific timeout as well. This would
ensure that the screen locks after a specific amount of time, such as 15
minutes. And the shell (Assuming it's back) will actually exit after a specific
timeout.
Thanks.  I've got that idle timeouts can be provided in one of several ways:
- Provided by the underlying application itself (such as the bash TMOUT variable).
- Provided by the SSH server, per client connection.
- Provided by a tool such as "screen" which runs between the client and the application.

I'm not aware of any way for Linux-PAM to provide an idle timeout.

For my use case, my application may not have an idle timeout function, and if I switch to openSSH which does not have an idle timeout function, I may need to use something like "screen" to provide this function.

The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per
https://github.com/mkj/dropbear/blob/master/default_options.h preprocessor
symbol DEFAULT_IDLE_TIMEOUT.
2. When the server starts via argument `-I 0`, and note SSH server
started by:
https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service where
shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).


Discussion:

I understand Yocto's current default (no timeout, meaning the SSH and
shell session stay open forever) may be correct for some users, but I
believe the OpenBMC project (downstream from Yocto) will want a more
secure default.  I would be happy with either keeping the current
(insecure) defaults, or with changing the default as I recommended
above, and seek to settle this question.
This is the key, the default should continue to be no timeout. HOWEVER, as
Richard mentions below, there needs to be a documented approach for specifying
the timeouts. My opinion is that these should be configurable via root owned
configuration files to ensure settings can't be "changed" without appropriate
permissions.

I've added this question to the OpenBMC security working group agenda.
Next meeting Wednesday August 4.  Access via
https://github.com/openbmc/openbmc/wiki/Security-working-group
I think what I'd like to see from the Yocto Project perspective is to document
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).
Agreed, I'm certainly interested in that.
I've tried to push https://github.com/openbmc/openbmc/wiki/Configuration-guide into https://github.com/openbmc/docs, but there was not enough interest. And yet questions come up regularly in the project's email list which can be answered by providing a link to the configuration guide.  So I know a configuration guide is useful.

I know you mentioned some work related to changing passwords too and trying
to get that documented with YP is still on my radar, I just don't have time
to do everything I'd like. Help with that would be much appreciated!
For my own products, I need to ensure that root logins are NOT allowed, no
default passwords are present and on first _CONSOLE_ login, the user to prompted
to set a password. (We do set a default user account, that has been given sudo
access.) Remote login's are not allowed until that has been done. (This is
already implemented and actually easy to accomplish. If there is additional
document requested about how to do this, let me know and I can share the steps
we do for the docs.)
I am still trying to move OpenBMC from root login to an admin account.  This is not yet accomplished because of the difficulty in changing this kind of configuration, and I believe projects downstream from OpenBMC have already shut off root access.  In any case, the configuration setting to do so are clearly identified. For example, you can see from the OpenBMC configuration guide that "root_user_mgmt" in https://github.com/openbmc/phosphor-user-manager/blob/master/configure.ac configures OE-core parameters along with some OpenBMC-specific code to enable or disable root logins.

I am interested in your method to ensure an initial password is set before allowing additional accesses.

Thank you,
- Joseph



--Mark

Cheers,

Richard









Mark Hatle
 

On 8/3/21 6:46 PM, Joseph Reynolds wrote:
On 8/3/21 1:54 PM, Mark Hatle wrote:

On 8/3/21 9:44 AM, Richard Purdie wrote:
On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:
Yocto security community,

Is Yocto interested in configuring a "SSH command shell session idle
timeout" to a more secure default?


Standards:

I suggest a per-session idle timeout of 60 minutes (one hour).
- OpenBMC's HTTPS server (BMCWeb) defaults to a one hour idle timeout.
https://github.com/openbmc/bmcweb/blob/master/include/sessions.hpp timeoutInSeconds

- NIST SP800-63B requires a timeout of 30 minutes for "assurance level
2" (high confidence that the authentication is still valid), or 15
minutes for "assurance level 2" (very high confidence).
https://pages.nist.gov/800-63-3/sp800-63b.html
- OWASP suggests idle timeouts of 15-30 minutes.
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration
To me the above means that you must have a way to do this, and it must be
configured as such... The Yocto Project doesn't care as much about the 'must be
configured as much', but definitely we should care about the 'you CAN configure
it as such, without impacting users who don't want a timeout.'
Thanks.  I understand and accept that Yocto will continue without any
SSH or shell session idle timeouts.
I will pursue this configuration change for my downstream project (OpenBMC).

Technical implementation:

I understand the timeout can be implemented either in the SSH session or
in the underlying application:

The bash shell offers the TMOUT variable for auto-logout to set the
session's idle timeout.  (This can be set to readonly before the shell
user gets control so they cannot change the timeout behavior.)
It's my understanding that this is typically done via PAM and standard
.bashrc/.profiles.

The OpenSSH server has removed the idle-timeout controls and recommends
doing it via the underlying application.
In the past, when I've worked on this stuff, we did timeout stuff in a
combination of 'screen', and ssh settings. Login would run through screen with
a timeout defined.

Screen could be set with a specific idle that required credentials, and then
bash (or other shells) would be set with a specific timeout as well. This would
ensure that the screen locks after a specific amount of time, such as 15
minutes. And the shell (Assuming it's back) will actually exit after a specific
timeout.
Thanks.  I've got that idle timeouts can be provided in one of several ways:
- Provided by the underlying application itself (such as the bash TMOUT
variable).
- Provided by the SSH server, per client connection.
- Provided by a tool such as "screen" which runs between the client and
the application.

I'm not aware of any way for Linux-PAM to provide an idle timeout.
PAM can forcably set the user's environment on login. Which can be used to
influence the other actions.

For my use case, my application may not have an idle timeout function,
and if I switch to openSSH which does not have an idle timeout function,
I may need to use something like "screen" to provide this function.
Yes, this is exactly why we used screen in the design I worked on. It ensured
the timeout, no matter what the running application was.

The dropbear SSH server can configure the per-session idle timeout in
one of two ways:
1. At compile time per
https://github.com/mkj/dropbear/blob/master/default_options.h preprocessor
symbol DEFAULT_IDLE_TIMEOUT.
2. When the server starts via argument `-I 0`, and note SSH server
started by:
https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service where
shell variable DROPBEAR_EXTRA_ARGS is not set.
3. Note the dropbear project default is 0 (unlimited = no timeout).


Discussion:

I understand Yocto's current default (no timeout, meaning the SSH and
shell session stay open forever) may be correct for some users, but I
believe the OpenBMC project (downstream from Yocto) will want a more
secure default.  I would be happy with either keeping the current
(insecure) defaults, or with changing the default as I recommended
above, and seek to settle this question.
This is the key, the default should continue to be no timeout. HOWEVER, as
Richard mentions below, there needs to be a documented approach for specifying
the timeouts. My opinion is that these should be configurable via root owned
configuration files to ensure settings can't be "changed" without appropriate
permissions.

I've added this question to the OpenBMC security working group agenda.
Next meeting Wednesday August 4.  Access via
https://github.com/openbmc/openbmc/wiki/Security-working-group
I think what I'd like to see from the Yocto Project perspective is to document
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).
Agreed, I'm certainly interested in that.
I've tried to push
https://github.com/openbmc/openbmc/wiki/Configuration-guide into
https://github.com/openbmc/docs, but there was not enough interest. And
yet questions come up regularly in the project's email list which can be
answered by providing a link to the configuration guide.  So I know a
configuration guide is useful.

I know you mentioned some work related to changing passwords too and trying
to get that documented with YP is still on my radar, I just don't have time
to do everything I'd like. Help with that would be much appreciated!
For my own products, I need to ensure that root logins are NOT allowed, no
default passwords are present and on first _CONSOLE_ login, the user to prompted
to set a password. (We do set a default user account, that has been given sudo
access.) Remote login's are not allowed until that has been done. (This is
already implemented and actually easy to accomplish. If there is additional
document requested about how to do this, let me know and I can share the steps
we do for the docs.)
I am still trying to move OpenBMC from root login to an admin account. 
This is not yet accomplished because of the difficulty in changing this
kind of configuration, and I believe projects downstream from OpenBMC
have already shut off root access.  In any case, the configuration
setting to do so are clearly identified. For example, you can see from
the OpenBMC configuration guide that "root_user_mgmt" in
https://github.com/openbmc/phosphor-user-manager/blob/master/configure.ac
configures OE-core parameters along with some OpenBMC-specific code to
enable or disable root logins.

I am interested in your method to ensure an initial password is set
before allowing additional accesses.
We turned off debug_tweaks in the image config, which ensured that no default
password was set.

EXTRA_IMAGE_FEATURES_remove = "debug-tweaks"

We then used the extra_user_parmas to add a user:

EXTRA_USER_PARAMS = "useradd -p '' petalinux;passwd-expire petalinux;usermod -a
-G audio petalinux;usermod -a -G video petalinux"

The above adds the user 'petalinux' with NO password required to login, we then
immediately expire the password (causing the first login to require a password).
The usermods give that user access to a few hardware resources that otherwise
you may need root for.

The who items above, along with the standard OpenSSH configuration preventing
password-less logins, will ensure that the only a local console login is
permitted. Since root doesn't have a password (:*: disabled password by
default), the user is forced to login to the account we've provided. Then on
first login forced to change their password.


Additionally we added a function to enable sudo access:

USERADDEXTENSION_append = " pln-useradd-suders"
EXTRA_USER_SUDOERS = "petalinux ALL=(ALL) ALL;"

This is what lets that user sudo, if I was doing a more secure system we
probably would have restricted it to specific sudo applications.

The code for that function is:

https://github.com/Xilinx/meta-petalinux/blob/release-2020.2.2_k26/classes/plnx-useradd-sudoers.bbclass


I've seen systems that do something like the above but randomize the account
name, and then present it during console boot. I'm not sure if that really
makes anything more secure. Not setting ANY default password, and requiring the
console login may not work on my systems without consoles -- but for us it
worked well since this device was plug it in, attach to a monitor, and add a
keyboard.

--Mark

Thank you,
- Joseph



--Mark

Cheers,

Richard













Richard Purdie
 

On Tue, 2021-08-03 at 18:46 -0500, Joseph Reynolds wrote:
On 8/3/21 1:54 PM, Mark Hatle wrote:

On 8/3/21 9:44 AM, Richard Purdie wrote:
On Tue, 2021-08-03 at 09:42 -0500, Joseph Reynolds wrote:
I've added this question to the OpenBMC security working group agenda.
Next meeting Wednesday August 4.  Access via
https://github.com/openbmc/openbmc/wiki/Security-working-group
I think what I'd like to see from the Yocto Project perspective is to document
and make these things easy to configure for users, along with testing in our QA
framework. There is never going to be one "right" solution for everyone but
making it easy/clear for users to do it would be ideal (which includes making it
easy for OpenBMC to configure what they need).
Agreed, I'm certainly interested in that.
I've tried to push
https://github.com/openbmc/openbmc/wiki/Configuration-guide into
https://github.com/openbmc/docs, but there was not enough interest. And
yet questions come up regularly in the project's email list which can be
answered by providing a link to the configuration guide.  So I know a
configuration guide is useful.
Yocto Project has extensive docs:

http://docs.yoctoproject.org/

from

http://git.yoctoproject.org/cgit.cgi/yocto-docs

and I'd love to see a security section added to these where we could start to collect 
best practises. Would you be interested in sending something for our docs on that 
subject?

Yocto Project does have people helping collate and edit the information if someone
is able to write out the "bare bones" information for them (cc'd Michael).

Cheers,

Richard