fork bomb still being possible out of the box in a couple of characters is funny to me
linuxmemes
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudo
in Windows. - No porn, no politics, no trolling or ragebaiting.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
That's the thing about Linux. The developers generally assume you want to do the thing you're doing. So they don't stop you.
Last time I was tempted to use suid, it was in order to allow an application I'd written to listen on 80 and 443. Fortunately I found the capabilities way of doing that (setcap 'cap_net_bind_service=+ep' executable
) and that was the first I ever heard of capabilities. I consider myself pretty Linux-savvy, but it was pretty recently that I learned about capabilities.
If this sounds like a security nightmare, thatβs because it is.
You can perfectly-reasonably implement suid binaries securely. They need to be simple and carefully constructed, and there shouldn't be many of them, but the assertion that suid is "a security nightmare" is ridiculous. sudo
itself relies on the suid bit.
I would describe need to proactively go out of your way to ensure a program is simple, minimal, and carefully constructed to avoid interactions potentially outside of a restricted security scope as a "security nightmare".
Being possible to do right or being necessary in some cases at the moment doesn't erase the downsides.
It's the opposite of secure by default. It throws the door wide open and leaves it to the developer and distro maintainer to make sure there's nothing dangerous in the room and that only the right doors are opened. Since these are usually not coordinated, it's entirely possible for a change or oversight by the developer to open a hole in multiple distros.
In a less nightmarish system a program starting to do something it wasn't before that should be restricted is for the user to get denied, not for it to fail open.
https://www.cve.org/CVERecord/SearchResults?query=Setuid
It may be possible, but it's got the hallmarks of a nightmare too.
Hard agree. This is why rust is getting so much attention, and the c/c++ crowd are so mad. They're happy just blaming it on a "skill issue" while losing their shit over [the rust crowd] saying "how about we don't let you in the first place."
They need to be simple and carefully constructed
Yeah, that's the difficult part. It's always better to go with the principle of least privilege (which is Capabilities is trying to do) than to just cross your fingers and hope that there are not bugs in your code. And who exactly is going to police people to make sure that their programs are "simple and carefully constructed"? The article I linked is about a setuid-related vuln in goddamn Xorg which is anything but.
Yes, Xorg being suid is stupid. That used to be needed due to several historical reasons, but is not any more.
But for 'su' or 'sudo' suid is still the right mechanism to use. Capabilities won't help, when the tool is supposed to give one full privileges. Of course, in some use cases no such command is needed, then the system can run with no suid. Similar functionality could be implemented without suid too (e.g. ssh to localhost), but with its own security implications, usually bigger than those brought but a mechanism as simple as suid (the KISS rule).
Does passwd rely on it as well? I'm curious to it's benefits, and what we're it's original use cases. Is it a necessary component of multi-user systems?
passwd uses it to update your password in an root-only-writable file
The nosuid
mount option disables this behavior per mount. Just be sure you don't use suid binaries.
Example: sudo
or doas
. I replaced those with switching to a tty with an already open root account on startup. Generally faster and more secure (you need physical access to get to the tty).
Does run0 use suid? From my understanding, it shouldn't.
From what I've read, no. Though it doesn't solve the fundamental problem of a root process handling untrusted input from a regular user.
The TTY method is IMO better as it ties privileges to a piece of physical hardware, bypassing the complexities of userspace elevation of privileges.