EasyInstaller user customization questions and possible feature request

We are attempting to move to EasyInstaller. Part of our Yocto configuration was a useradd recipe that added a user of our own. Our requirements have been:

  • Add our own customer user with its own home directory with ~/.ssh/authorized_keys, etc. EasyInstaller doesn’t let us add a custom home directory unless we put it somewhere under /etc?
  • For security reasons, we would like to remove the built-in initial “torizon” user completely. We haven’t found in EasyInstaller documentation if this is acceptable, could you share any implications of doing that.
  • We also remove the ability to login with a password completely for security reasons. Once we do that, the TorizonCore builder tool can no longer be used to isolate further changes, as only username and password options are available to authenticate. Thus we must keep in a temporary/dev password that is passed in a very insecure manner during development until we get to the last stage, then we can disable password access and test whether we got the image right. Feature request, allow key based auth for isolation at some point!
  1. Please let us know implications of removing the Torizon user with EasyInstaller.

  2. When adding a custom user, is there any way we can specify the home directory in the OSTree /var hierachy? Could that be allowed in the future?

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hand-shake,

Addressing your queries regarding customization with the Toradex Easy Installer and user management within TorizonCore:

  1. Implications of Removing the Torizon User with EasyInstaller:
    Removing the default “torizon” user could impact the ease of initial setup and default access, as this user is pre-configured for immediate use, facilitating initial tests and deployments. However, if your project’s security requirements necessitate this, it can be done. You would need to ensure that your custom user is properly configured to allow for necessary access and functionalities that the “torizon” user would typically provide. This includes SSH access, permissions for relevant directories, and any development tools you plan to use. It’s crucial to thoroughly test your system after making such changes to confirm that all intended functionalities remain accessible and secure.

  2. Adding a Custom User and Specifying the Home Directory:
    Within the context of TorizonCore and the OSTree system, user home directories are typically managed under the /home directory. If you’re looking to place the home directory within the /var hierarchy, this is not standard practice and could lead to complications, especially with stateless and atomic update features of OSTree-based systems like TorizonCore. However, for custom configurations, you could theoretically create a symbolic link from the user’s home directory in /home to a location in /var, but this would need to be carefully managed and tested, especially across updates. As of now, specifying a custom home directory location directly within the OSTree configuration is not a standard feature. Future support for such a feature would depend on broader community demand and the implications for system stability and security.

Regarding your feature request for key-based authentication for isolation in the TorizonCore Builder tool, it’s a valid point for enhancing security. While current versions focus on username and password authentication, the evolution of the tool could potentially include more secure authentication methods, including SSH keys, especially as security needs and practices evolve. Feedback like yours is crucial for guiding development priorities.

For both of these concerns, it’s important to carefully consider the balance between custom security requirements and the maintainability of your system, especially regarding future updates and compatibility with the broader Torizon ecosystem.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

How to Modify a Toradex Easy Installer Image | Toradex Developer Center.

Greetings @eldonmetz,

Okay, first of all let’s make sure you’re using the right terminology for everything here.

We are attempting to move to EasyInstaller

I think you mean Torizon OS here right? Easy Installer is just a tool to flash our images, it’s not a full OS itself.

Add our own customer user with its own home directory with ~/.ssh/authorized_keys, etc. EasyInstaller doesn’t let us add a custom home directory unless we put it somewhere under /etc?

Here are you talking about the TorizonCore Builder tool? Easy Installer doesn’t do customization.

For security reasons, we would like to remove the built-in initial “torizon” user completely. We haven’t found in EasyInstaller documentation if this is acceptable, could you share any implications of doing that.

Again assuming you’re talking about Torizon OS here instead of Easy Installer. First of all, what security requirement is this that requires you to remove the torizon user?

Next, it’s hard to say what the full implications would be. A lot of our tooling and processes expect the torizon user to be present in the OS in some form or way. It’s hard to say what the consequence would be if you were to remove this. I wouldn’t be surprised if something were to break or stop working correctly.

We also remove the ability to login with a password completely for security reasons. Once we do that, the TorizonCore builder tool can no longer be used to isolate further changes, as only username and password options are available to authenticate. Thus we must keep in a temporary/dev password that is passed in a very insecure manner during development until we get to the last stage, then we can disable password access and test whether we got the image right. Feature request, allow key based auth for isolation at some point!

You can just manually create the changes directory yourself. It doesn’t need to come from the isolate command. In which case you wouldn’t need to do what you’re doing now. You would just need to be a bit careful when manually creating the changes directory yourself to make sure your customizations are actually coherent. This would be a good guide to read if you do this: TorizonCore Builder Tool - Commands Manual | Toradex Developer Center

Please let us know implications of removing the Torizon user with EasyInstaller.

As I said I would expect quite a few things to break or not work correctly at all. I don’t have a full list as we don’t run tests on our OS without the torizon user as it’s the only normal user on the OS by default.

When adding a custom user, is there any way we can specify the home directory in the OSTree /var hierachy? Could that be allowed in the future?

OSTree specifically by design does not track anything in /var. As you can see here: Adapting existing mainstream distributions | ostreedev/ostree

OSTree links /home under /var/home therefore it is not tracked by OSTree. Meaning this change can’t be meaningfully tracked by OSTree. You can create files/directories in /var during runtime, it just won’t be tracked by OSTree. In your case if a home directory is truly needed here you could create it in another location that is tracked by OSTree. Either that or have a script that generates the home directory during runtime in the usual location. But if you want this to be tracked by OSTree then this won’t work, keep that in mind.

Best Regards,
Jeremias

Thank you for the reply, sorry for the confusion with EasyInstaller. I’ve been mixing up TorizonCore Builder with EasyInstaller. However, I was trying to refer to TorizonCore Builder as our alternative to Yocto for the building our custom image. I realize TorizonCore Builder takes a supported TorizonOS image and allows you to customize it as an alternative to using Yocto to build that with the layers and recipes.

What other distributions, build processes are you aware of that limit you to a “default” user like the “torizon” user? It is unbelievable to me that all your customers would be expected to use your default user in production? Is that really true? If it is, I find it simply amazing. Can it be renamed without all these assumptions breaking like you surmise? The only user I know that is expected to be there on linux platforms is “root”, never a OS specific one like “ubuntu”, “debian”, …

I realize I can create the .tcattr and put the files in there myself, believe me, I’ve been playing with that trying to get that image to flash successfully as I pare it down to just a couple minor files. However, the isolate command is a convenience in your toolkit, do you disagree allowing your customers to use it with ssh key authentication would be helpful? I’m taking it that feature request is rejected?

I understand /var/home is not tracked. However, we want to create a different user. Will TorizonCore Builder let us put changes in /var, or are we limited to /etc for a new user we add to TorizonOS?

Hi @jeremias.tx , my question regarding the custom user home directory was likely worded poorly. focused on the one way of doing it with a useradd followed by isolating the /etc/… file changes. However, this approach fails because the user’s home directory is not there on boot and thus the user cannot login, nor can they use ssh key authentication.

Let me ask these simple questions:

  • How can we use TorizonCore Builder to customize a TorizonOS image to add a custom user with a home directory that has pre-provisioned authorized_keys file and initial password?
  • Do you have any examples or documentation on how to best do this?
  • Do you have documentation / or a list of services in your requirements that depend on the torizon user being present. I’m especially interested in this from a vulnerability standpoint.

Thanks,

Eldon

What other distributions, build processes are you aware of that limit you to a “default” user like the “torizon” user? It is unbelievable to me that all your customers would be expected to use your default user in production? Is that really true? If it is, I find it simply amazing. Can it be renamed without all these assumptions breaking like you surmise? The only user I know that is expected to be there on linux platforms is “root”, never a OS specific one like “ubuntu”, “debian”, …

I never said you have to use the torizon user in production. All I said was that there might be some repercussions from removing it form the system completely. We have many customers that use Torizon OS who add another user to be used in production. But, they still keep the torizon user present on the system. I can’t say I’ve heard of another customer of ours where they had a requirement that forced them to remove the torizon user from the OS.

By the way you did not answer my question, what specific security requirement is it that is making you do this?

I realize I can create the .tcattr and put the files in there myself, believe me, I’ve been playing with that trying to get that image to flash successfully as I pare it down to just a couple minor files. However, the isolate command is a convenience in your toolkit, do you disagree allowing your customers to use it with ssh key authentication would be helpful? I’m taking it that feature request is rejected?

You’re presuming quite a bit. Not enough time has even passed for me to discuss this to our team internally. Such a request even if it were accepted, would take some time to get anywhere given our large backlog of other issues and requests. Considering as of now we’d only have your name to put behind this request. I couldn’t find any other similar request in our backlog that this request could work off of.

This is why I’m focusing on trying to support you with what can be done now, in the present time. There’s no guarantee your request will even be done in a time-frame that would be helpful to you. Which is why I’m not giving you false expectations about this.

I understand /var/home is not tracked. However, we want to create a different user. Will TorizonCore Builder let us put changes in /var, or are we limited to /etc for a new user we add to TorizonOS?

TorizonCore Builder uses OSTree for filesystem customization, so no /var is not possible. You can customize any file location that OSTree tracks and allows. The isolate command only looks at /etc, since a majority of filesystem customization happen here, but you could in theory create a custom changes directory for other locations. But you still need to adhere to the rules of OSTree.

How can we use TorizonCore Builder to customize a TorizonOS image to add a custom user with a home directory that has pre-provisioned authorized_keys file and initial password?

I just did a quick test with the following:

  • Run the following commands on the device to create a new user with password with home directory in /etc
# sudo useradd -d /etc/home/test_user test_user
# sudo passwd test_user
  • Use TorizonCore Builder to isolate these changes.
  • Create a custom image with these changes
  • Flash custom image onto the device.

On my resulting custom image I can login as test_user and the home directory is where I expect it to be:

test_user@verdin-imx8mm-06738453:~$ pwd
/etc/home/test_user

Do you have documentation / or a list of services in your requirements that depend on the torizon user being present. I’m especially interested in this from a vulnerability standpoint.

At the moment no, because it’s not really something we ever had to consider before. As I said this has never really been asked of us in the past. I can ask around, but I don’t expect anyone to just have a straightforward list ready.

Best Regards,
Jeremias

Greetings @jeremias.tx ,

Thank you for this info, we will attempt to remove the torizon user to see what happens. We appreciate the suggestions and are successfully using the custom user with a home directory in /etc/home.

Security is our number one concern and it is getting more complicated. We must ensure that password login cannot happen, nothing is listening on open ports to anything but a very secured (and time limited) vpn connection, and that no internal services using a user with advanced permissions (such as the torizon user) is reaching out to external services that can be compromised. Since I don’t know enough right now about the torizon user on the provided TorizonOS image we are customizing, I’m just paranoid and assuming that I can’t trust this torizon user and what it may be reaching out to (uptane update server, Torizon Cloud, etc.). I’m not saying we can’t trust those services, but we need to analyze the risks and ensure we are doing our best to protect/track/mitigate vulnerabilities. I may just be too paranoid, but that is safer. :slight_smile:

Best,

Eldon

Interesting, I’ve heard a lot of different security requirements and concerns from various customers from various industries. Though I think this is the first time I’ve heard a concern with regards to the torizon user on the OS.

If I understand you correctly then this isn’t some industry enforced, or security certification requirement, yes? It’s more of a self requirement from your team on your product, correct?

Out of curiosity have you or your team had issues in the past with “untrusted” users on your systems before?

Best Regards,
Jeremias

Greetings @jeremias.tx ,

I suggest you read this as a starting point.
https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF.

I would start by looking at section 5.1. Use unique usernames and account settings.

NSA recommends removing all default configurations and reconfiguring each device
with a unique and secure account for each administrator. Do not introduce any new
devices into the network without first changing the default administrative settings and
accounts.

I’ve discussed your requirements here at length internally with my colleague @leo.tx. We do recognize that this requirement to remove the torizon user from the system is valid in certain secure scenarios. It’s something we’d like to give more time to in the future. Presently it’s not something we can immediately prioritize within our team in the near future.

At the present time the following can be done with regards to user security:

  • Disable password SSH/auth for the “torizon” user. This is something you mentioned before and should be doable.
  • Docker containers that directly connect to the internet running with the UID of a safer, less privileged user. Containers allow you to customize the user that is being used inside the container for more controlled access. Furthermore there are further configurations to control what Docker container has access to on the host system, limiting access even more if needed.
  • Reduce privileges of the torizon user to the minimum required. You can try to limit the default privileges and permissions of the torizon user without removing it completely. This is less likely to result in possible unforeseen issues.

Best Regards,
Jeremias