Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the HLD for SONiC reset local users' passwords #1577

Merged
merged 1 commit into from
Oct 14, 2024

Conversation

azmy98
Copy link
Contributor

@azmy98 azmy98 commented Jan 4, 2024

This document provides general information about reset local users' passwords during init implementation in SONiC

The scope of this document is to cover definition, design and implementation of SONiC reset local users' passwords during init feature.

Submodule PR Title Status
sonic-buildimage Feature YANG Model & SystemD service GitHub issue/pull request detail
sonic-utilities CLI commands GitHub issue/pull request detail
sonic-swss-common Config DB Schema GitHub issue/pull request detail
sonic-platform-common Feature Base Class Implementation GitHub issue/pull request detail

@azmy98 azmy98 force-pushed the dev-long-reset-button-hld branch 15 times, most recently from a166dfa to d98771f Compare January 4, 2024 12:47
doc/SONiC_long_reset_button_press_hld.md Outdated Show resolved Hide resolved
LongRebootPress().start()
```

The feature is added to the init flow as long as the we set the ```ENABLE_LONG_RESET_BUTTON_PRESS``` in ```rules/config```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we set ENABLE_LONG_RESET_BUTTON_PRESS = n during compilation, will it avoid adding the long-boot service to SONiC?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, same as we do for:
CHANGE_DEFAULT_PASSWORD ?= y


# Warmboot and Fastboot Design Impact

The feature will not have any impact on fast reboot or warmboot.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There needs to be explicit check in the script not to start on warmboot/fastboot. Please refer to https://github.com/sonic-net/sonic-host-services/blob/722b7962f95e8d602a9a60e77356826e9f68891c/scripts/hostcfgd#L1506

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is interesting. The system should be able to determine if this reboot is either a physical press on the switch or a warm/fast reboot by calling the get_reboot_cause function that we are use in the script. So, I don't think we need it. @dgsudharsan, can you confirm?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As part of the meeting discussion, I added the changes to support warmboot/fastboot.

@azmy98 azmy98 force-pushed the dev-long-reset-button-hld branch 10 times, most recently from 44d3aac to caa4ddb Compare January 9, 2024 13:59
@zhangyanzhao
Copy link
Collaborator


description "LONG_RESET_BUTTON part of config_db.json";

container STATE {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest to avoid STATE name for the CONFIG_DB data as it looks like a read-only data, please use STATUS.

Copy link
Contributor Author

@azmy98 azmy98 Feb 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@venkatmahalingam , just to be aligned, do we need to change the leaf as well? or just the container name?
because I see in other places 'state' as a command.


The long reset button press feature implementation shall support the following:

1. On long reboot press, the OS will restore the local users' configurations, by deleting non-default users and restoring default passwords for default users and expiring these passwords due to security conecerns.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the use-case mainly to reset the password of the default user? if no, why cant we login to the switch with the default user to delete the non-default users explicitly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I changed the feature name accordingly. the fearture will be reset local users for the default users and in the default implementation this will be triggered by a long reset button

4. On short reset button press, the current init flow should not be affected and should boot normally.
5. Feature should be enabled or diabled by setting compliation flag to true or false.
6. Feature can be disabled and enabled using CLI command.
7. The feature is enabled by default.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure above statement is true, I think, it's disabled by default, please clarify.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to disabled :)

@azmy98 azmy98 force-pushed the dev-long-reset-button-hld branch from 5ae9a60 to 939c65e Compare February 7, 2024 11:10

This feature will be a built-in SONiC feature. There will be three main files to consider in this feature:

1. ```src/sonic-platform-common/sonic_platform_base/reset_local_users_passwords_base.py``` - The default behavior implementation will reside in this file, including when to trigger the feature and how to reset the local users' configurations.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we want to name the plugin reset_local_users_passwords? If the trigger of this flow is going to be only long press, I recommend renaming it reset_button.py or something similar.

This feature will be a built-in SONiC feature. There will be three main files to consider in this feature:

1. ```src/sonic-platform-common/sonic_platform_base/reset_local_users_passwords_base.py``` - The default behavior implementation will reside in this file, including when to trigger the feature and how to reset the local users' configurations.
2. ```platform/<vendor-path>/sonic_platform/reset_local_users_passwords.py``` - The vendor specifc implementation of the feature, each vendor can decide what is the trigger cause to start the functionality and how it is implemented.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. If the trigger is going to pressing reset button alone, lets rename it accordingly.

2. ```platform/<vendor-path>/sonic_platform/reset_local_users_passwords.py``` - The vendor specifc implementation of the feature, each vendor can decide what is the trigger cause to start the functionality and how it is implemented.
3. ```src/sonic-host-services/scripts/reset-local-users-passwords``` - The python file that will be called on service start during init that imports the vendor's specific implementation.

The default behavior will delete non-default users and restore the original passwords of the default users and expire them based on the content of the file of ```/etc/sonic/default_users.json``` on long reboot press.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we address the security concern raised in the sonic community meeting? This behavior will reset the passwords alone and not data or configuration and thus its a security concern if someone resets and logs in with default password and obtains all the data. Should we consider resetting configuration and other important files?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a recovery mechanism, if users would like to use this in order to recover their own passwords (which they forgot), without deleting the data on top of the switch - this is the way to do so.
Customers that are using AAA methods will not be affected by this - so let's reduce this to local users only.
In case of a local user, if we have a PW reset, then the default users will be available and might pose a security risk. This is why customers that do not want a recovery mechanism should disable this functionality.
There is indeed a tradeoff between functionality and user experience to security in this feature, but it is manageable.
Also, in order to execute this attack and attack will have to have physical access to the switch, and only after a reboot (which can be tracked since the system will experience downtime)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the concern was raised by @lguohan . I think another scenario is when a switch is RMA, the switch's data could be easily accessed if the long reset was enabled. This might be the motivation for the security concern. @lguohan Can you please see if Yarden's comment addresses your concern?


# Warmboot and Fastboot Design Impact

The feature will not have any impact on fast reboot or warmboot.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This daemon itself shouldn't run when the boot type is warmboot or fastboot as the reset button press results only in cold boot. Warmboot and fastboot have strict timing requirements and since this flow will not happen during warm or fastreboot, lets make sure not to run the daemon.
Please update the same in HLD as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will update it also in the requirements



```
class LocalUsersConfigurationReset:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend not to add code into the HLD. the HLD should contain design and flow diagrams. The code is subject to change and will lead to confusion in the future.

### Show command
**The following command display long-reset-button-press configuration:**
```bash
root@sonic:/home/admin# show local-users-passwords-reset
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer the show command to show the last reboot reset button state, rather than just showing the configuration. Can you please publish the last reboot reset button state to state_db and use it to display in show, so that user will be aware if a long press is detected after the current boot?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the user can know that from the reboot-cause, why do we need to have double commands for it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If show reboot-cause can cover it, I am fine with it

@azmy98 azmy98 force-pushed the dev-long-reset-button-hld branch from 939c65e to f57585c Compare February 18, 2024 14:37
@qiluo-msft qiluo-msft requested review from liuh-80 and maipbui March 18, 2024 07:06
@qiluo-msft
Copy link
Contributor

@liuh-80 Could you help review?

@liat-grozovik
Copy link
Collaborator

@azmy98 when do you expect to share the code PRs?

@liat-grozovik
Copy link
Collaborator

it was decided to remove this HLD for SONiC. PR is closed.

@liat-grozovik
Copy link
Collaborator

I see no further comments and all seems to be addressed.
@liuh-80 @venkatmahalingam FYI the PR is going to be merged soon.

Appreciate if you can also review the code PRs and provide your feedback.

@liat-grozovik
Copy link
Collaborator

@venkatmahalingam would you mind to provide code PR review feedback as well?

@zhangyanzhao
Copy link
Collaborator

YANG PR will be reviewed in the YANG workgroup meeting. Other PR review is on-going.

@zhangyanzhao
Copy link
Collaborator

@liat-grozovik will bring this to TSC to get guidance how to handle such PR which needs 2nd reviewers.

@fastiuk
Copy link
Contributor

fastiuk commented Aug 13, 2024

@liat-grozovik / @zhangyanzhao can we merge this PR?

@fastiuk
Copy link
Contributor

fastiuk commented Oct 8, 2024

@liuh-80 could you please merge it?

@fastiuk
Copy link
Contributor

fastiuk commented Oct 14, 2024

@liuh-80 / @zhangyanzhao / @liat-grozovik could you please merge it? It was approved a month ago

@liat-grozovik liat-grozovik merged commit e05fc6f into sonic-net:master Oct 14, 2024
1 check passed
@zhangyanzhao
Copy link
Collaborator

code PRs are not merged, move to backlog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: MovedToBacklog
Status: MovedToBacklog
Development

Successfully merging this pull request may close these issues.