[Security] rootless - Githubissues

Creating a feature request

Is your feature request related to a problem? Please describe:

The default settings, user, script permissions, are in many many cases running with too much permission as root, best example is the dietpi-morsecode, but in generate just having an SSH server running where root login is allowed is just goes against security best practices. sudo is around for decades, let's try to set an example which lead the users to the right path, a "de-rooting" would be great on this project.

Describe the solution you'd like:

Ideal case scenario, no script's / services needs to run as root, all can sudo up.

Describe alternatives you've considered:

The only real alternative for this is fork too to the amount of changes needed, which is not just a huge amount of work, but then splitting the power of the OSS community again.

Additional context

I'm working in SecOps, and yet I'm founding many of the scripts provided by the project super handy, just to name few dietpi-backup or dietpi-drive_manager but can't force myself to compromise the otherwise secure setup I built to use the project as it is, I'm just cherry-picking the good bits.

Vote for this feature on FeatHub: https://feathub.com/MichaIng/DietPi/

@kisst Many thanks for your request.

Let me get this right:

There a possibly a few scripts that actually do not need to run as root. dietpi-morsecode is a good example. It currently reads the input file (to translate to morse code) from /root/, but it can simply read from ~/ which allows it to be run as any user, which makes it even more usable. On my ToDo 😃!
But all other examples you mention simply require root. You cannot mount drives and edit fstab or backup the whole file system (by preserving permissions) without having root permissions. Of course one can always use e.g. sudo dietpi-backup.
Is your idea that scripts should not run as root or with sudo throughout but instead call sudo themselves for the commands where required? This indeed would mean a huge rework and a LOT of sudo calls each script, since all (most of) these software/config scripts are simply system tasks. These are no, lets say single software installers, where the target dir can be chosen to be the users home dir and the only sudo tasks is the APT installs.
Compare to other similar utilities like raspi-config, setup-odroid or ARMbain debian-config and debian-software. All of them check for root permissions once and otherwise ask to be called as sudo.
And I personally find it more clear/transparent security-wise, to explicitly tell the user once that root is required (ask for sudo) then to silently call it multiple times within the script, which is also a large overhead performance-wise and spams the log AND once needs to take care about environment variable losses, which means even more work.

But I am opened for examples and will go through the scripts. Maybe we find some where indeed root permissions are required only on 1-2 commands where sudo can be used safely within the script. Needs a slight rework of root permissions check to test $UID == 0 || out=$(sudo -nv) || { [[ $out == *'sudo:'* ]] && <requires_interactive_password_input>; } or something similar.

I know raspi-config so let's stick to that example, and then we might able to get on a common ground.

From the official docs page

You will be shown raspi-config on first booting into Raspbian. To open the configuration tool after this, simply run the following from the command line:

 > sudo raspi-config

The sudo is required because you will be changing files that you do not own as the pi user.

So the first number 1 difference between DietPi and Raspbian that the default user there is not an elevated user, it does have sudo, but not superadmin rights as an entry step. You are right most of the script does not work without higher privilege and they do need sudo to make them work, for sure you can't do fstab edit and apt install and etc as a simple user, but on a normal usage, you still login as normal user, you still run some of the things as your own basic user, and only when you need more permission then you sudo up.

The problem is not that you need root, but about the fact that you can't sudo up, due to hardcoded locations, imports and etc can't recall exactly all, the issues I faced but will test it again, tonight.

Sticking to the example of raspi-config, you have the options to su to root and just run it, sure that works, but also you can just run it as a normal user with sudo, this isn't true for many of the dietpi scripts. I don't have a full list right now which I had a trouble with as at some point I give up and just went back to the default Raspbian to avoid root everywhere, but I will test it again (hopefully) tonight and let you know the issues I faced, I think even the simple adding the extra lines in bashrc and path just freaking the whole shell out.

And one more slightly off-topic but yet still relevant for the project topic, the package installer idea is just great, and the principal of storing "install runbooks" online and just run them is something I been also considering for a while, but the infra behind it and the forum as a storage, just doesn't feel right. I do have an idea / proposal which might be a bit more generic, a bit more security, operation friendly, and here you can read about the principals. I already started to read up some of the dietpi script to get motivation / validation that my super simple and early stage data model would be able to capture all fields, what's needed to install "anything". But I really didn't have much time to work on it so, it's not much more then idea yet, however I think the approach of having minimal footprint installation, and smart defaults, would make the dietpi installation scripts a nice minimalist flavor option.

Let me know what's your thoughts around the glid project, and I will get back to you with the exact problems around using the dietpi script with sudo, btw you can find me on keybase in case you want to chat instead.

@kisst

So the first number 1 difference between DietPi and Raspbian that the default user there is not an elevated user, it does have sudo, but not superadmin rights as an entry step.

On DietPi you can login with the dietpi user btw, but actually I plan to make that a system user to run programs and share permissions only. Long term actually only a shared permissions group is required to allow downloader frontents access the backends and media players + file servers access the downloads etc. The plan is to give user the choice to create an unprivileged user account on first login (or via dietpi.txt for auto-creation on first boot) and optionally disable root login completely. However yes currently root login is default by early concept.

Whether or not root login has any security disadvantage over unprivileged login with sudo permissions is another question. If an attacker manages to login as root or as unprivileged user that can run sudo, the result is exactly the same. Only difference is that an inexperienced Linux user/beginner cannot that easily accidentally damage the system as non-root user, so basically a self-protection 😉. Rare other case, if you open SSH to www, root is a common brute-force target. However I would not open SSH to web anyway, outside of VPN, or at least enable key authentication + fail2ban + use a non-default port (not 22) then. Non-default port turned those random brute-force attempts to zero in my case for several years. I wrote down some security advices, open for review/enhancement: https://github.com/MichaIng/DietPi/wiki/Security-recommendation I plan to integrate this into DietPi as well at some points.

The problem is not that you need root, but about the fact that you can't sudo up, due to hardcoded locations, imports and etc can't recall exactly all, the issues I faced but will test it again, tonight. ... Sticking to the example of raspi-config, you have the options to su to root and just run it, sure that works, but also you can just run it as a normal user with sudo, this isn't true for many of the dietpi scripts.

I am not aware of any case where sudo would not work. Please report back if you find one. Running any script as sudo should result in exactly the same behaviour (+ environment) as running it as root directly. This is also the reason why we never use $HOME (if you mean this by hardcoded locations), as it would always result in /root anyway, which is also wanted. Most software is installed on a server/client basis with its own daemon user, so should not run as different user with different directories/environment, depending on your current login user. For desktops and games we just added the option to choose the auto-login user account when selecting the dietpi-autostart option.

And one more slightly off-topic but yet still relevant for the project topic, the package installer idea is just great, and the principal of storing "install runbooks" online and just run them is something I been also considering for a while, but the infra behind it and the forum as a storage, just doesn't feel right.

Not sure if I understood correctly? What do we store on the forum? We use APT where we can (note that DietPi is a Debian-only OS/distro, so no generic method like implementing yum or such is required), otherwise official deb packages, in rare cases such stored on our server, where the one or the other distro version does not ship the required version, npm/pip/... where required. Using different methods is a basic difficulty of Linux distros, however often a choice as well, based on which version you need, most current vs more stable or any special for compatibility reason. So I think it is not possible to use any generic concept here (always try this first, else that, otherwise...) if you want to assure that multiple software titles can be installed an run beside each other. The whole dietpi-software scripts is based on muuuch experience and many bug fixes due to external changes, since every software title comes with its own special need that change from time to time. This is an ongoing process of keeping things working and the install methods change for many software titles each DietPi version and individually/depending on the architecture and distro version (Jessie vs Stretch vs Buster).

Let me know what's your thoughts around the glid project

Interesting idea indeed if you switch between different distros. However DietPi is a Debian-only project and as above, in many cases you can't avoid to choose e.g. python-pip as install method even that apt-get would be possible as well. And then the package names differ from source to source. So I don't see a chance to have a generic method there, besides dietpi-software itself is that "generic" method for the available set of software on DietPi systems 😉.

btw you can find me on keybase in case you want to chat instead

Lets stay here for now, in case someone else want to jump in/contribute discussion/ideas.

Bottom line, indeed DietPi from the starting concept was a "root"-only distro, so even all software titles ran as root which avoided all permission issues that you otherwise run into. It was a hard and long task to switch to software-individual run user while keeping cross-access permissions up where required. Allowing to auto-login (dietpi-autostart options) as non-root was another step and I aim go on increasing security and make the whole system more non-root compatible and flexible where possible. Any input or help with this is highly appreciated 🙂 !

MichaIng / DietPi

[Security] rootless #2972