It turns out that, if ran, this command can actually corrupt the ‘atomic’ system:
sudo dd if=/dev/urandom of=/dev/disk0
Yes, I tried and ran it. I think this is an issue that should be fixed. Why should the root user have enough privileges to directly write to the disk where the system is installed without asking the filesystem first? Is there a way to limit the root user’s privileges so much so that it won’t be able to do basically anything, that is related to system modification, except of the strictly controlled set of whitelisted commands that don’t have the potential to destroy the system (e.g. through SELinux of AppArmor). Such a root user will have elevated (compared to the other users in the system), but not absolute, control over the system.
Indeed the choice of immutable term has been always criticized. Indeed, at least Fedora, opted to switch to atomic term.
In any case “immutable” is referred to the OS (even if the system is actually mutable: how else would updates be made?) and not to the hardware or firmware. Your PC is still a PC (a general-purpose device) and not a locked system.
Its not the terminology that concerns me, its the actual implementation and functionality of the system. Dont change the descriptions to fit what system is. Change the system to better fit the term “immutable”. A loaded system should not be able to destroy itself from within itself programmatically. Hardware properties are irrelevant.
If you don’t want a user to be able to mess up the system, you should not give them sudo privileges.
Even if somehow the Atomic systems were changed so that even the root user did not have direct access to devices, they would still need to be able to run rpm-ostree and ostree commands that would still be able to mess up the system practically as much as you like.
Not to mention they would have access to all user files in /var/, where everything of value on the system will be anyway.
No. I want a process (ran within the system) to not be able to mess up the system even if I run it as root user. I want the system to be completely ‘rootless’ and for the root user privileges to be somewhat higher than in other users, but not absolute. It is a state of mind. So that the only way to to destroy the system would be to load another system and have it access the drive on which the 1st system is installed.
You don’t get what I am saying. In my case, it is not, since I am not concerned with the wording, but with the actual functionality and operation of the system. I couldn’t care less for how the actual real-life things that exist are referred to in human language. I just want the system to not be as it is, patching this security flaw, to make it as I want it to be.
Probably a system like the one you are talking about needs a strict integration with the hardware, so you are talking about iPhone and many Android devices, isn’t it?
Why not make it like that?
Isnt macOS like that? Correct me if I am wrong, but AFAIC, you can’t just use this command to overwrite the whole drive with random data (provided the SIP feature is enabled). Why not make it like that also? Also why should it require hardware-software integration? Why not just make some SELinux adjustments to limit the root user’s privileges to strictly limit what it is allowed to do (preferably with whitelist method)?
and to the specific issue: A root user will always be able to break the system. This is unavoidable and “fixing” that would likely carry a huge amount of additional stuff that would be nonstandard.
Instead, a core goal should be to make nonwheel accounts work. you would install the system with a wheel account - which is the default - log in and create a user account. With the wheel account you can also install system flatpaks, which the user account can use.
That user can then
update the system with rpm-ostree (also automatically in the background)
create toolboxes or distroboxes and do whatever they want in there
run appimages or binaries
do all the stuff you would want
create user session virtual machines (With GNOME Boxes or virt-manager, after removing the QEMU system session and adding a QEMU user session)
flash USB sticks
mount, use and unmount encrypted external media (graphically too)
use su admin in the terminal, and use sudo in there
can use run0 instead of sudo, I guess?
They cannot
modify /var and /etc
install or remove RPM packages
add system flatpak repositories
install or remove system flatpaks
create rootful podman containers or distroboxes
use the QEMU system session, so some VM features dont work, but not many
change partitions of any disks
You see the system is already quite usable, but has some issues. I am not sure what nonwheel users can do if they can enter the admin accounts password, if AUTH_ADMIN is used in the polkit rules, this could mean a nonwheel user can enter the admin user password and do elevated things anyways.
The beauty of Fedora’s atomic desktops is that there’s no need for root privileges to perform system and software updates, hence one can limit administrative actions to GUI apps only.
One could even go that far as to have it’s main user without wheel permissions, and keep an “admin” user only for those few tasks where required.
Why should it be the “unavoidable”? Is there a fork or a different project that aims at exactly what I am describing?
I see now that the project does not seem to aim exactly at what I thought it does. Instead of aiming to be absolutely programmatically indestructible it sets a different goal. Are there systems that:
strive to prevent system modification from within itself at any cost
still aim to provide decent level of flexibility, functionality and freedom while not at the expense of the aforementioned goal
not closed-source.
Perhaps there are systems that use a modified version of the linux kernel that limits ‘root’ user’s privileges enough to prevent any tinkering with the drive whatsoever. Or that do not have a ‘root’ user at all?
Even if the stuff that needs to be done to achieve this is ‘non-standard’, I dont care, I just want it.
Ubuntu is making one with everything is snaps, desktop is snaps, kernel is snaps, drivers are snaps and structure is just like android all sandboxed and containerized with no root access but can still change stuff as user desktop install just kde desktop snap and done remove gnome desktop and done
Bro, its the matter of personal preference. Changing that makes sence for me subjectively, because of this preference of mine. Not all users want it to be the way it is by default, I am sure there is a great portion of them who would prefer to be able to run ANY command or script within the system without the fear of anything “breaking” (or at least, changes being easily revertable).
This seems to be a question of what most of the Linux community is used to and their “philosophy” rather than actual practical incapability of making it happen.
Since dd is a low-level utility, which ignores the underlying system (i.e. the read-only file-system in case of atomic desktops), in order to solve the raised issue/preference, right off the top of my head I would say the OS would need to either ship without these utilities, or to somehow hide the system disks from such utilities. While the first option seems doable but rather restrictive from most users’ point of view, I imagine the latter would imply efforts which are much higher than the obtained results.
I understand the need for an “indestructible” OS though.
Removing all the utilities that have the potential of corrupting the system won’t be restrictive if there will be an option to toggle this type of behavior in a separate environment outside of the main system or/and during the installation process
may want to fix 2 polkit rules like in my both rejected change proposals