3 ms·

I think this comes primarily from trying to add a separate management tool on top, instead of leveraging the OS structure themself. There is a reason, why most

I think this comes primarily from trying to add a separate management tool on top, instead of leveraging the OS structure themself. There is a reason, why most directories are specified to be readonly. Also writable XOR persistent is mostly true. The only things required to be writable are /tmp, /var and /home. /tmp is wiped at least on every boot or is even just a ramdisk. /var can be cached or reset to the predefined settings on boot. /home needs to be managed, that is true. But you wouldn't want every users directory on every host anyway, instead you want to populate them on login. That is typically done by libpam. /usr is expected to be shared among hosts, host-specific stuff goes into /usr/local for a reason, and as a sysadmin you can decide to simply not have host specific software. EDR/AV is basically unnecessary, when you only mount things either writable or executable. And you don't want the users to start random software or mount random USB-sticks anyway. > Back then it was like nobody who had ever actually been a sysadmin had ever taken an honest crack at Linux and all the hype was coming from home users who had no idea what herding boxen was actually like. Unix has over 50 years of history of being primarily managed by sysadmins instead of home users. While Linux is not Unix, it has inherited a lot. The whole system is basically designed to run a bunch of admin configured software and is actually less suitable for home users. I would say the primary problem was accessing it with a Windows mindset.

mapontosevenths 11mo ago
> EDR/AV is basically unnecessary, No, its not and never will be. Even if it were technically unnecessary (in some hypothetical future where privilege escalation became impossible?), legal, compliance, and insurance requirements would still be there.
- 1718627440 11mo ago
  The problem is that EDR is basically a rootkit, by using it you enable a huge attack surface instead of being able to have stuff e.g. immutable. That tradeoff only makes sense, when you don't trust and control the OS itself. This is more of a problem with proprietary OSes like Windows. Otherwise you would rather integrate this into the OS itself.
  - mapontosevenths 11mo ago
    > That tradeoff only makes sense, when you don't trust and control the OS itself. That's totally accurate, but you're missing the fact that we fundamentally don't (and can never) trust the OS or any other part of a general purpose computer. In general purpose computing you have a version of Descartes brain in a vat problem (or maybe Plato's allegory of the cave if you want to go even further back). https://iep.utm.edu/brain-in-a-vat-argument/ https://iep.utm.edu/brain-in-a-vat-argument/ To summarize: We can't trust the inputs even if the OS is trusted, and if the OS is trusted can't trust the compiler, and even if we trust the compiler we can't trust the firmware, but even if we trust the firmware we can't trust the chips it runs on, and even if we trust those chips we can't trust the supply chain, etc. "Trust" is fundamentally unsolvable for any Turing machine, because all trust does is move the issue further down the supply chain. I know this all sounds a bit hypothetical, but it's not. I can show you a real world example of every one of those things having been compromised in the past. When there is money or lives at stake people will find a way, and both things are definitely at stake here. So what we have to do is trust, but verify, or at the very least log everything that happens and that's largely what those EDR products exist to do. Maybe we can't stop every attack, even in theory, but we take a crack at it and while we're at it we can log every attack to ensure that we can at least catch it later. There just isn't any version of this world in which general purpose computers don't require monitoring, logging, and exploit prevention.
    - 1718627440 11mo ago
      Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. If you think the hardware works against you, then you are screwed.
      - mapontosevenths 11mo ago
        > Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. It doesn't have to be "a random company". Microsoft, for example, now ships EDR as part of the operating system. Many companies prefer other vendors for their own reasons. Sometimes one concern is the exact issue you're describing. By using another vendor outside of MS they can layer the security rather than putting all their eggs in a Microsoft designed basket. We sometimes call that a "security onion" in cyber. I have no idea what the Linux version of that would even look like though. I imagine you'd just choose one of the many 3rd party EDR's from "random companies." It's another reason I asked the original question about how Sysadmins cope with Linux these days. MS has an entire suite of products designed to meet these security, regulatory, and compliance problems. Linux has... file permissions I guess?
mapontosevenths 11mo ago
> the primary problem was accessing it with a Windows mindset. The early Unix systems you're talking about were mainframe based. Modern client-server or p2p apps need an entirely different mindset and a different set of tools that Linux just didnt have the last time I looked. When they audit the company for SOX , PCI-DSS, etc we can't just shrug and say "Nah, we decided we don't need that stuff." That's actually a good thing though, because if it were optional well meaning folks like you just wouldn't bother and the company would wind up on the evening news.
- 1718627440 11mo ago
  > When they audit the company for SOX, PCI-DSS, Maybe I am missing something, but that seems orthogonal to ensuring host integrity? I didn't argue against logging access and making things auditable, by all means do that. I argued against working against the OS. It is not like integrity protection software doesn't exist for Linux (e.g. Tripwire), it is just different from Windows, since on Windows you have a system where the default way is to let the user control the software and install random things, and you need to patch that ability away first. On Linux software installation is typically controlled by the admin and done with a single file database (which makes it less suitable for home users), but this is exactly what you want on a admin controlled system. Sure, computing paradigms have changed, but it is still a good idea to use OS isolation like not running programs with user rights.
  - mapontosevenths 11mo ago
    I just mean to say that while you absolutely should work to configure the OS to a reasonable baseline of security, you also still need a real EDR product on top of it. Even if security were "solved" in Linux (it's not), it would still often be illegal not to have an EDR and that's probably a good thing.
    - 1718627440 11mo ago
      > you also still need a real EDR product on top of it. Well that's my point. You don't need third-party software messing up with the OS internals, when the same thing can be provided by the OS directly. The real EDR product is the OS.
GoblinSlayer 11mo ago
> And you don't want the users to start random software python ~/my.py wget | bash
- 1718627440 11mo ago
  I guess you wouldn't install wget in that installation and patch programming languages to follow the executive bit or also remove them. Also you can't make it physically impossible for employees to not e.g. screenshot things and take them home. You can forbid it and try to enforce it, but some amount of trust is needed. Willing action needs to be taken for what it is, an deliberate action by that user. If that user is allowed to access that data, than I don't see what is wrong with him doing that in an automated way.
msm_ 11mo ago
>EDR/AV is basically unnecessary, when you only mount things either writable or executable Sounds good, except: * scripting languages exist. The situation is even worse on Linux than on Windows (because of the sysadmin focus). You need at least /bin/sh installed and runnable on any POSIX system. In practice bash, python, perl and many more are also always available. * exploits exist. Just opening a pdf file may execute arbitrary code on a machine. There is no way to avoid that by just configuring your system. And it will happen sooner or later, especially if nation states are involved. The idea that your systems are somehow unhackable because you... mount everything W^X is... not based in reality. Of course it's a great idea, but in practice you need defense in depth, and you need to have a way to Detect and Respond to inevitable Endpoint breaches. I don't love EDR/AVs, but they mitigate real attacks happening in the real world.

mapontosevenths 11mo ago

> EDR/AV is basically unnecessary, No, its not and never will be. Even if it were technically unnecessary (in some hypothetical future where privilege escalation became impossible?), legal, compliance, and insurance requirements would still be there.

1718627440 11mo ago
The problem is that EDR is basically a rootkit, by using it you enable a huge attack surface instead of being able to have stuff e.g. immutable. That tradeoff only makes sense, when you don't trust and control the OS itself. This is more of a problem with proprietary OSes like Windows. Otherwise you would rather integrate this into the OS itself.
- mapontosevenths 11mo ago
  > That tradeoff only makes sense, when you don't trust and control the OS itself. That's totally accurate, but you're missing the fact that we fundamentally don't (and can never) trust the OS or any other part of a general purpose computer. In general purpose computing you have a version of Descartes brain in a vat problem (or maybe Plato's allegory of the cave if you want to go even further back). https://iep.utm.edu/brain-in-a-vat-argument/ https://iep.utm.edu/brain-in-a-vat-argument/ To summarize: We can't trust the inputs even if the OS is trusted, and if the OS is trusted can't trust the compiler, and even if we trust the compiler we can't trust the firmware, but even if we trust the firmware we can't trust the chips it runs on, and even if we trust those chips we can't trust the supply chain, etc. "Trust" is fundamentally unsolvable for any Turing machine, because all trust does is move the issue further down the supply chain. I know this all sounds a bit hypothetical, but it's not. I can show you a real world example of every one of those things having been compromised in the past. When there is money or lives at stake people will find a way, and both things are definitely at stake here. So what we have to do is trust, but verify, or at the very least log everything that happens and that's largely what those EDR products exist to do. Maybe we can't stop every attack, even in theory, but we take a crack at it and while we're at it we can log every attack to ensure that we can at least catch it later. There just isn't any version of this world in which general purpose computers don't require monitoring, logging, and exploit prevention.
  - 1718627440 11mo ago
    Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. If you think the hardware works against you, then you are screwed.
    - mapontosevenths 11mo ago
      > Sure, that is why you trust a blackbox software from some random company running as a rootkit, whose concrete version you do not even control, because it is remotely updated by them. It doesn't have to be "a random company". Microsoft, for example, now ships EDR as part of the operating system. Many companies prefer other vendors for their own reasons. Sometimes one concern is the exact issue you're describing. By using another vendor outside of MS they can layer the security rather than putting all their eggs in a Microsoft designed basket. We sometimes call that a "security onion" in cyber. I have no idea what the Linux version of that would even look like though. I imagine you'd just choose one of the many 3rd party EDR's from "random companies." It's another reason I asked the original question about how Sysadmins cope with Linux these days. MS has an entire suite of products designed to meet these security, regulatory, and compliance problems. Linux has... file permissions I guess?

mapontosevenths 11mo ago

> the primary problem was accessing it with a Windows mindset. The early Unix systems you're talking about were mainframe based. Modern client-server or p2p apps need an entirely different mindset and a different set of tools that Linux just didnt have the last time I looked. When they audit the company for SOX , PCI-DSS, etc we can't just shrug and say "Nah, we decided we don't need that stuff." That's actually a good thing though, because if it were optional well meaning folks like you just wouldn't bother and the company would wind up on the evening news.

1718627440 11mo ago
> When they audit the company for SOX, PCI-DSS, Maybe I am missing something, but that seems orthogonal to ensuring host integrity? I didn't argue against logging access and making things auditable, by all means do that. I argued against working against the OS. It is not like integrity protection software doesn't exist for Linux (e.g. Tripwire), it is just different from Windows, since on Windows you have a system where the default way is to let the user control the software and install random things, and you need to patch that ability away first. On Linux software installation is typically controlled by the admin and done with a single file database (which makes it less suitable for home users), but this is exactly what you want on a admin controlled system. Sure, computing paradigms have changed, but it is still a good idea to use OS isolation like not running programs with user rights.
- mapontosevenths 11mo ago
  I just mean to say that while you absolutely should work to configure the OS to a reasonable baseline of security, you also still need a real EDR product on top of it. Even if security were "solved" in Linux (it's not), it would still often be illegal not to have an EDR and that's probably a good thing.
  - 1718627440 11mo ago
    > you also still need a real EDR product on top of it. Well that's my point. You don't need third-party software messing up with the OS internals, when the same thing can be provided by the OS directly. The real EDR product is the OS.

GoblinSlayer 11mo ago

> And you don't want the users to start random software python ~/my.py wget | bash

1718627440 11mo ago
I guess you wouldn't install wget in that installation and patch programming languages to follow the executive bit or also remove them. Also you can't make it physically impossible for employees to not e.g. screenshot things and take them home. You can forbid it and try to enforce it, but some amount of trust is needed. Willing action needs to be taken for what it is, an deliberate action by that user. If that user is allowed to access that data, than I don't see what is wrong with him doing that in an automated way.

msm_ 11mo ago

>EDR/AV is basically unnecessary, when you only mount things either writable or executable Sounds good, except: * scripting languages exist. The situation is even worse on Linux than on Windows (because of the sysadmin focus). You need at least /bin/sh installed and runnable on any POSIX system. In practice bash, python, perl and many more are also always available. * exploits exist. Just opening a pdf file may execute arbitrary code on a machine. There is no way to avoid that by just configuring your system. And it will happen sooner or later, especially if nation states are involved. The idea that your systems are somehow unhackable because you... mount everything W^X is... not based in reality. Of course it's a great idea, but in practice you need defense in depth, and you need to have a way to Detect and Respond to inevitable Endpoint breaches. I don't love EDR/AVs, but they mitigate real attacks happening in the real world.