Given that such OS modifications would require a formal process of change request, I would move this topic from this section (Project Discussion) to either Ask Fedora (in case you would like to obtain a solution to your question, even as workaround), or to The Water Cooler, for a more informal discussion on this topic.
Are you fine with that?
Can you keep it here? Silverblue and Kinoite are the closest projects to the goal I am describing. I would like the changes to me merged into the main system
I won’t move it then (someone else managing this section might do so though). However, the topic might get more attention in the other sections.
Given that dd is not an isolated tool but rather part of GNU coreutils, and since your request is quite niche, I would also consider the option of workarounds, rather than hoping for a systemic change (at least not on the short term).
Hi there! 
I should began in “wataercooler” section. You can always be an admin without ‘dd’ 
Here are some approaches (from simple to “paranoid mode” 
): 1. Simple sudo restriction: Create a new admin group with limited powers: bash groupadd wheelnodd Then in /etc/sudoers.d/restrict-dd: bash %wheelnodd ALL=(ALL:ALL) ALL, !/bin/dd, !/usr/bin/dd 2. SELinux approach (if you’re feeling adventurous): Create custom policies to restrict direct disk access. Though remember - with great complexity comes great responsibility (and debugging headaches! 
) 3. The “Belt and Suspenders” approach: Combine sudo restrictions with polkit rules. But honestly, that might be overkill for Silverblue, which already has: - Immutable root filesystem - rpm-ostree transactions - Built-in rollback capability Remember: Sometimes simpler is better! 
The more complex your security setup, the more likely you might lock yourself out or create unexpected issues. Go with ‘sudo ostree admin undeploy 0’ if you want to cancel unwanted transaction. IF you allready reboot, then reboot once again and keep pressing SHIFT button after POST UEFI/BIOS screen. If your concerns are about term ‘Immutable’; then you may be right.
If you want something implemented with a security objective, you need to define a threat model with at least the following questions answered (not exhaustive):
As we have no context here, I would say:
Then, doing the following:
would satisfy your ask, at the cost of making some things impossible right now (major version upgrades for example).
It’s a personal goal of mine to be able to run a system under a fully unprivileged user (but we’re not there yet).
If it’s “I want administrative users to not be able to destroy an Atomic Desktop system”, then it’s a non goal for the project.
This likely will not do what you want as you can just open a shell as root and run the command directly:
$ sudo -i
# dd ...
Denylisting commands in sudo generally does not work.
Sorry if it’s not the case, but your comment @go-win-out looks like a ChatGPT generated one.
Hi,
I didn’t notice the word ‘proposal’ in the thread, sorry. I was sure that the author of the thread was concerned that he would accidentally replace the system image with pseudo-random data. My post above is not any proposal for changes to ‘atomic desktops’. I fully agree with your statement that the level of paronoi needs to be adjusted according to a realistic risk assessment. It was not GPT And there is no case
2 questions:
If the answer to the #2 is yes then maybe you would consider the possibility of giving an option to install the system without the root user in it?
Fedora is an open source, community project. Changes and goals are set collectively by contributors to the project. Major changes generally go through the change process which requires approval by FESCo, which is elected by contributors. Fedora general goals are listed at Fedora’s Mission and Foundations :: Fedora Docs. There isn’t a more precise list of goals for the Atomic Desktops as far as I know.
In general, just like other open source projects, the changes are defined by what people are working on and what they can convince the maintainers to merge.
“Removing the root user” can mean many things:
/etc/passwd? Similarly, but that would not really “remove it”.usermod -some-option-i-forgot root.The response by @siosm notwithstanding as I do not have a particular security posture in mind, there are things that can be done. Some more drastic than others. Absolute security users are happy to live with almost certianly will never happen.
How about installing to a worm device? So atomic becomes replace storage media.
More earthbound I do advocate running as a regular user so your example becomes
$ sudo dd if=/dev/urandom of=/dev/vda
username is not in the sudoers file.
Then when elevated privileges are required, give the admin user a different account with sudo only to be used for admin tasks. This is security 101 stuff that has been taught for decades. I think even MS has the possibility of being useful without the user being a member of the local administrator group like was required in earlier versions.
The use of polkit in fedora is a compromise that would be nice to get rid of. Basically with polkit tasks that need elevated privileges are run with elevated privileges even when initiated by an unprivileged user. It improves usability but decreases security. On terra firma it is considered an appropriate trade-off.
Maybe some of the techniques used in the realm of containers will be helpful. Concepts leveraged with the kernel lsm, cgroups, namespaces, seccomp, discretionary and mandatory access controls etc. are not fully exhausted. Interesting security isolation using podmansh (as well as another way to do toolbox/distrobox stuff) might be an example.
Keeping the conversation going is appreciated!
Why would you intentionally overwrite your (I’m assuming it’s your boot disk) system partition using dd? I mean come on, people have to take some responsibility for their actions in such a case.
Sure thing, the way I did it was an intentional experiment and I didnt loose any data.
I suppose that the type of security hardening I propose can be used against a local incompet actor rather than a malicious one.
For example:
I guess we can all agree that many things just dont work without root access or/and straight up demand it and while understand the need to be able to fumble in the system’s “guts” to achieve some results I also think that some users might want to have a safe foolproof environment to have a system up and running no matter what commands they feed it.
What about the use case, when the dd is used on purpose, e.g., to destroy the data on purpose and not destroying data would put a person in a danger ? In a sort of “kill switch” situation.
Like I said, that would need to be done from a different environment, not the immutable system. E.g. recovery or BIOS
Even if a person must do that right now, not having “another environment” ?
That would be a con of using such an approach. You sacrifice some flexibility to the gods of stability. And, in my opinion, having a version of the OS with such an approach is worth tge shot
That’s just when it’s mounted, right? Anyway it doesn’t really prevent you from destroying the data on that disk if you have root, you just need to do it by other means.
Preventing writing directly to a device when it’s mounted is a good idea though, but that would need to be about filesystem handling in the kernel and is not really about things that can be done in a distribution anymore.
Like what, for example?
I suppose yes… System drive is mounted by default first thing when it boots up?
I dont understand, are you saying that the Fedora Kinoite in its current state can’t be change to be more like macOS? If yes, why not?
It’s something that would need to be done in the kernel so well outside of the scope of packaging KDE in Fedora Atomic which is what the Kinoite project is about.
