• 4 Posts
  • 101 Comments
Joined 1 year ago
cake
Cake day: June 1st, 2023

help-circle


  • That’s called ‘privilege escalation’, and replacing system level calls with user level calls is closely watched for and guarded against with many different security measures including SELinux.

    You’ve already outed yourself multiple times in this thread as someone who doesn’t understand how security in the real world works. Take the L and try to learn from this. It’s okay not to understand something. But it’s very important to recognize when that happens and not claim to understand better than someone else.


  • I strongly disagree with your premise. Separating authentication and privilege escalation adds layers of security that are non-trivial and greatly enhance resilience. Many attacks are detected and stopped at privilege escalation, because it happens locally before a user can stop or delete the flow of logs.

    If I get into your non-privileged account I can set up a program that acts like sudo

    No you cannot. A non privileged user doesn’t have the access necessary to run a program that can accomplish this.

    And even if they do it’s too late anyway because I’ve just compromised root and locked everybody out and I’m in there shitting on the filesystems or whatever. Because root can do anything.

    Once again, you didn’t privilege escalate, because once you have a foothold (authentication) you don’t have the necessary privileges, so you must perform reconnaissance to identify an exploitable vector to privilage escalate with. This can be any number of things, but it’s always noisy and slow, usually easy to detect in logs. There is a reason the most sophisticated attacks against well protected targets are “low and slow”.

    And if I can’t break into your non-privileged account then I can’t break into a privileged account either.

    You’re ignoring my points given regarding the risks of compromised keys. If there are no admin keys, there are no remote admin sessions.

    These artificial distinctions between “non-privileged” and “superuser” accounts need to stop. This is not good security, this is not zero trust. Either you don’t trust anybody and enforce explicit privilege escalation for specific things, or just accept that you’re using a “super” paradigm and once you’ve got access to that user all bets are off.

    Spoken like someone who has never red teamed or purple teamed. Even admin accounts are untrusted, given only privileges specific to their role, and closely monitored. That doesn’t mean they should have valid security measures thrown away.


  • Wouldn’t separate SSH keys achieve the same?

    Separate ssh keys for the user and the admin? Yeah, see point 2, admins should not be remotely accessible.

    Really? How, exactly? Break the ssh key authentication? And wouldn’t that apply to all accounts equally?

    Keys aren’t perfect security. They can easily be mishandled, sometimes getting published to GitHub, copied to USB drives which can easily be lost, etc.

    Further, there have been attacks against SSH that let malicious actors connect remotely to any session, or take over existing sessions. By not allowing remote access on privileged accounts, you minimize risk.

    Forcing a non privileged remote session to authenticate with a password establishes a second factor of security that is different from the first. This means a cracked password or a lost key is still not enough for a malicious actor to accomplish administrative privileges.

    A key is something you have

    A password is something you know

    So, by not allowing remote privileged sessions, we’re forcing a malicious actor to take one more non-trivial step before arriving at their goals. A step that will likely be fairly obvious in logs on a monitored machine.




  • “We had a huge chunk of our engineering staff spending time improving FreeBSD as opposed to working on features and functionalities. What’s happened now with the transition to having a Debian basis, the people I used to have 90 percent of their time working on FreeBSD, they’re working on ZFS features now … That’s what I want to see; value add for everybody versus sitting around, implementing something Linux had a years ago. And trying to maintain or backport, or just deal with something that you just didn’t get out of box on FreeBSD.”

    I still hold much love for FreeBSD, but this is very much indicative of my experience with it as well. The tooling in FreeBSD, specifically dtrace, bhyve, jails, and zfs was absolutely killer while Linux was still experiencing teething problems with a nonstandard myriad of half developed and documented tools. But Linux has since then matured, adopted, and standardized. And the strength of the community is second to none.

    They’ll be happier with Linux.





  • Disingenuous how? You don’t think Linux solved a real day to day need of it’s first users?

    Sure, from Torvald’s perspective, it was a project specifically to solve a small problem he had. He wanted to develop for a nix platform, but Minix wouldn’t work on his hardware, and the other *Nixs were out of reach.

    And this was generally true in the market as well. Linux arrived just in time and was “good enough” to address a real gap, where Minix was limited in scope to basically just education, Hurd was in political development hell, and the other Nixs were targeted at massive servers and mainframes. Linux filled the “*Nix for the rest of us, inexpensively” niche, eventually growing in scope to displace its predecessors, despite their decades of additional professionalism and maturity.

    That niche is now filled, the gap no longer exists. A “New Linux” wouldn’t displace Linux, because the original already suits the needs we have well enough. This is precisely why the BSDs and Solaris were “too little, too late”. They were in many ways better than Linux, but the problems they solve compared to Linux are tiny and highly debatable. Linux addressed a huge, day to day need of people who were motivated to help.




  • My favorite city builder in decades. A few notes.

    Pros:

    • Easy mode is relaxing and quite easy.
    • Medium mode is a fun challenge at first, eventually becoming fairly chill as you advance in skill and confidence.
    • Hard mode is always fairly hard, especially on harder maps.
    • There are many resources to manage, but none that feel burdensome.
    • The game is extremely thematic, it feels alive with charm.
    • Graphics are excellent, though sometimes graphical glitches can still be encountered.
    • The water. It’s so hard to explain to someone who hasn’t encountered this system before, but water is life in this game, and it’s both beautiful graphically, and extremely well simulated by physics. Learning to control the water, and see the shortest paths to end water scarcity with beaver engineering is an amazingly fun and unique aspect of the game.
    • Mods are well supported and the community is vibrant.

    Cons:

    • Not a ton of content. They’ve been very good about adding new mechanics (badwater, extract, etc) but there’s still just 2 races of beaver and a dozen or so maps.
    • No directed experience. In similar games I’ve enjoyed a campaign, challenge maps/scenarios, weekly challenges, a deeper progression system, just… Something to optionally set your goals. There’s nothing of the sort in the vanilla game. It’s fully open ended and there’s only one unlock outside of your progress though the resource tree in a map.

    All in all, I highly recommend it, especially at the modest asking price. If you love city builders, charming and beautiful art, thematic settings, dynamic challenge, and solution engineering, this is a fantastic game for you.

    Other games I’ve enjoyed that scratch similar itches:

    • KSP
    • Cities: Skylines (but Timberborn has been far more compelling)
    • Factorio
    • Mindustry
    • Planet Zoo (Timberborn has less of a directed experience, but is otherwise completely superior)
    • Gnomoria
    • Banished
    • Tropico series (though I view this as more casual)

    Get it and have fun is my recommendation.