4 ms·

The moment you delegate your security or stability concerns to a third party, all bets are off. Period. Package maintainers, RedHat, whoever. Maybe the patch f

The moment you delegate your security or stability concerns to a third party, all bets are off. Period. Package maintainers, RedHat, whoever. Maybe the patch fixes a vulnerability, maybe it creates one. Maybe the company pushing security is really pushing mindshares of ecosystems for subscription revenue and industry influence. Build from source; keep your packages as minimal as possible; keep your permissions as granular and restricted as you can manage; and pray to your gods of choice. I can't understand why people are so anxious to embrace so much unneeded complexity. Things that "just work" always just work until they just don't.

kelnos 6y ago
I'm pretty sure "build from source" is out of reach for most people (from a technical ability standpoint), and for those who could do that, most have better things to do with their time. If your threat model includes intentionally malicious packages from Red Hat, Debian, or whomever, ok, but understand that you're a miniscule fraction of a percent of the user base. And you'd better be auditing the source that you compile as well.
- ownagefool 6y ago
  The words "threat model" gets thrown around, but I'm not actually sure "our threat model didn't include our OS vendor" would be considered an acceptable excuse. Sure, we have reasons to trust Redhat; - You can look at their working practices ( Good coding hygiene, Peer Review, Tools, etc ) - You can make the commercial argument ( they make money by doing the right thing, it's not in their interest to hack us ) But ultimately we're still explicitly trusting 1000s of people here, so reality is much more nuanced. - Hardern your OS, i.e. only install the bare essentials. - Monitoring for processes or networking traffic doing unexpected things. Thus, you evidence that you reasonably trust the vendor but you'd expect to see an alert were to prove false. Probably a better use of "threat model" would be, we don't need to place trust in developer end user devices because we instead place our trust in our SCM, CI/CD and the SDLC process.
  - kelnos 6y ago
    > The words "threat model" gets thrown around, but I'm not actually sure "our threat model didn't include our OS vendor" would be considered an acceptable excuse. I can't recall any threat-modeling session I've been a part of, or any infosec security professional I've talked to, who has seriously considered the OS vendor as a threat. "Our threat model didn't include the OS vendor" absolutely is an acceptable excuse. Your mitigations (only install bare essentials, network monitoring) are good advice in general, and people should be doing those things regardless of any perceived threat from the OS vendor. Aside from that, really the only way you can absolutely harden yourself assuming a hostile OS vendor is to... not use an OS, and build your entire system from scratch. Which, again, sure, might be a perfectly reasonable thing to do for some ultra-sensitive applications, but -- again -- that is a teeny tiny fraction of a percent of what's actually happening out in the world.
    - ownagefool 6y ago
      First point, depends on what you work on I guess. Most of the world doesn't patch, but that doesn't mean managing your dependencies isn't important. On the last point, doing it all yourself probably isn't actually better. Most people don't have the time in the day to invent the universe, so you're always back to figuring out how you establish trust.
- bonestormii_ 6y ago
  That it is difficult and most people have "better things to do", fine, I can agree that this can't work for like, all computer users. But if you really care about security, and if you are managing a linux OS where you have a lot of deep access to the system, I think saying "I have better things to do with my time than understand the system I'm managing; that's what vendors are for" is a lazy perspective. Consider this: https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Order of events here: - RedHat creates systemd to handle init and daemons--something that used to be handled mostly by shell scripting and much simpler tools. - Debian and RHEL based systems adopt systemd. That's most Linux systems. - About 6-7 years later, an issue is noticed and reported by a user. If a user creates a service to be run under a username beginning with a number, which some distros (not RHEL or Debian though), systemd validates the name (why?) by matching it against a regex. -If validation on any field fails, they categorically ignore that field and run the service. -In this case, because it is the user name, it runs the service as root instead of the user name. -Their response? "This is how the system handles all fields. We do it for consistency and compatibility. Closed." -That was 3 years ago. This was never fixed. "It's not a bug! Just don't give systemd a potentially valid user name that looks like that!" So using the daemon system promoted by RedHat (who we trust!) has created a situation where a process--possibly a server or something public facing--could be run as root without you immediately realizing it. You don't care to understand your system, but you do have to operate it. RedHat won't do that part for you. So, you could create these conditions unknowingly. It wasn't malicious, but what's important is that it isn't necessary. Look at what kinds of questions did the RedHat maintainers ask? "I wonder what tool allowed you to generate this file?" A totally useless question, given these files are frequently generated manually. "It's the tools fault! Whatever it is. Even though it might be a valid username on your system." A better question might be "Why do we have to validate/parse the username field at all?" After all, parsing bugs are well-known for creating security vulnerabilities, and if the name is invalid, then there will be no user, and the service will fail in the same way it does when the username string is syntactically valid but there is simply no user. In short, they have a product that "helps you manage your OS; and from RedHat (who we trust!)", yet we find that it increases complexity; does unnecessary work; and results in a bug that could allow a process to run root when it should not. This scenario is so similar to the flatpak sandbox issue. "It's not a bug. It's just that most people are misconfiguring it." Fine! But you chose to embrace the added complexity of a system (flatpak) that you just don't actually need. It has pros and cons. It's not a matter of trusting RedHat not to be malicious--it's trusting them to make that judgement for you. Their judgement is not perfect. There is a medium that exists between "audit every line of source in the system yourself" and "trust implicitly everything a vendor says and does". I think that RedHat is reputable and trustworthy, and they are trying to push Linux forward, but they are simultaneously reinforcing their position as industry experts through creating software that "eats linux". It's not malicious, it's just the nature of their existence. Your interests and their interests are not the same, so it makes sense to consider things for yourself.
ownagefool 6y ago
Often because you only have so much time in the day, so you can't actually verify all the code and hardware. Once you realise you're going to need to deal with running stuff you don't entirely trust, you it makes some sense to extend this beyond the bare necessities and dip your toe into productivity improvements. Problem is, much of the industry is full of charlatans that copy and buy as opposed to understand. You end up with orgs that spend $20 million security products but refuse to pay for the expertise to configure it. The reality is we have, we have a lack of skills, especially around InfoSec and most people just mimic what they've heard, rather than really think about it. On average, companies don't compete for talent, and they don't have enough skills and discourse to hire better than they have anyway, so it doesn't really matter what they run.

kelnos 6y ago

I'm pretty sure "build from source" is out of reach for most people (from a technical ability standpoint), and for those who could do that, most have better things to do with their time. If your threat model includes intentionally malicious packages from Red Hat, Debian, or whomever, ok, but understand that you're a miniscule fraction of a percent of the user base. And you'd better be auditing the source that you compile as well.

ownagefool 6y ago
The words "threat model" gets thrown around, but I'm not actually sure "our threat model didn't include our OS vendor" would be considered an acceptable excuse. Sure, we have reasons to trust Redhat; - You can look at their working practices ( Good coding hygiene, Peer Review, Tools, etc ) - You can make the commercial argument ( they make money by doing the right thing, it's not in their interest to hack us ) But ultimately we're still explicitly trusting 1000s of people here, so reality is much more nuanced. - Hardern your OS, i.e. only install the bare essentials. - Monitoring for processes or networking traffic doing unexpected things. Thus, you evidence that you reasonably trust the vendor but you'd expect to see an alert were to prove false. Probably a better use of "threat model" would be, we don't need to place trust in developer end user devices because we instead place our trust in our SCM, CI/CD and the SDLC process.
- kelnos 6y ago
  > The words "threat model" gets thrown around, but I'm not actually sure "our threat model didn't include our OS vendor" would be considered an acceptable excuse. I can't recall any threat-modeling session I've been a part of, or any infosec security professional I've talked to, who has seriously considered the OS vendor as a threat. "Our threat model didn't include the OS vendor" absolutely is an acceptable excuse. Your mitigations (only install bare essentials, network monitoring) are good advice in general, and people should be doing those things regardless of any perceived threat from the OS vendor. Aside from that, really the only way you can absolutely harden yourself assuming a hostile OS vendor is to... not use an OS, and build your entire system from scratch. Which, again, sure, might be a perfectly reasonable thing to do for some ultra-sensitive applications, but -- again -- that is a teeny tiny fraction of a percent of what's actually happening out in the world.
  - ownagefool 6y ago
    First point, depends on what you work on I guess. Most of the world doesn't patch, but that doesn't mean managing your dependencies isn't important. On the last point, doing it all yourself probably isn't actually better. Most people don't have the time in the day to invent the universe, so you're always back to figuring out how you establish trust.
bonestormii_ 6y ago
That it is difficult and most people have "better things to do", fine, I can agree that this can't work for like, all computer users. But if you really care about security, and if you are managing a linux OS where you have a lot of deep access to the system, I think saying "I have better things to do with my time than understand the system I'm managing; that's what vendors are for" is a lazy perspective. Consider this: https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Order of events here: - RedHat creates systemd to handle init and daemons--something that used to be handled mostly by shell scripting and much simpler tools. - Debian and RHEL based systems adopt systemd. That's most Linux systems. - About 6-7 years later, an issue is noticed and reported by a user. If a user creates a service to be run under a username beginning with a number, which some distros (not RHEL or Debian though), systemd validates the name (why?) by matching it against a regex. -If validation on any field fails, they categorically ignore that field and run the service. -In this case, because it is the user name, it runs the service as root instead of the user name. -Their response? "This is how the system handles all fields. We do it for consistency and compatibility. Closed." -That was 3 years ago. This was never fixed. "It's not a bug! Just don't give systemd a potentially valid user name that looks like that!" So using the daemon system promoted by RedHat (who we trust!) has created a situation where a process--possibly a server or something public facing--could be run as root without you immediately realizing it. You don't care to understand your system, but you do have to operate it. RedHat won't do that part for you. So, you could create these conditions unknowingly. It wasn't malicious, but what's important is that it isn't necessary. Look at what kinds of questions did the RedHat maintainers ask? "I wonder what tool allowed you to generate this file?" A totally useless question, given these files are frequently generated manually. "It's the tools fault! Whatever it is. Even though it might be a valid username on your system." A better question might be "Why do we have to validate/parse the username field at all?" After all, parsing bugs are well-known for creating security vulnerabilities, and if the name is invalid, then there will be no user, and the service will fail in the same way it does when the username string is syntactically valid but there is simply no user. In short, they have a product that "helps you manage your OS; and from RedHat (who we trust!)", yet we find that it increases complexity; does unnecessary work; and results in a bug that could allow a process to run root when it should not. This scenario is so similar to the flatpak sandbox issue. "It's not a bug. It's just that most people are misconfiguring it." Fine! But you chose to embrace the added complexity of a system (flatpak) that you just don't actually need. It has pros and cons. It's not a matter of trusting RedHat not to be malicious--it's trusting them to make that judgement for you. Their judgement is not perfect. There is a medium that exists between "audit every line of source in the system yourself" and "trust implicitly everything a vendor says and does". I think that RedHat is reputable and trustworthy, and they are trying to push Linux forward, but they are simultaneously reinforcing their position as industry experts through creating software that "eats linux". It's not malicious, it's just the nature of their existence. Your interests and their interests are not the same, so it makes sense to consider things for yourself.

ownagefool 6y ago

Often because you only have so much time in the day, so you can't actually verify all the code and hardware. Once you realise you're going to need to deal with running stuff you don't entirely trust, you it makes some sense to extend this beyond the bare necessities and dip your toe into productivity improvements. Problem is, much of the industry is full of charlatans that copy and buy as opposed to understand. You end up with orgs that spend $20 million security products but refuse to pay for the expertise to configure it. The reality is we have, we have a lack of skills, especially around InfoSec and most people just mimic what they've heard, rather than really think about it. On average, companies don't compete for talent, and they don't have enough skills and discourse to hire better than they have anyway, so it doesn't really matter what they run.