4 ms·

Hm. That's more mechanism-as-policy than I like, e.g.: Refusing all RSA keys smaller than 1024 bits The next release of OpenSSH will remove support for runnin

Hm. That's more mechanism-as-policy than I like, e.g.: Refusing all RSA keys smaller than 1024 bits The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled That's not really the sort of decision application programmers should be making for sysadmins.

slasaus 10y ago
> That's not really the sort of decision application programmers should be making for sysadmins. As a programmer you have the right (or maybe even obligation?) to write secure software and I would argue software that's hard or impossible to use insecurely. It should live up to the standards of the time of release, not the time of the release of the first version (in case of OpenSSH that would be more than seventeen years ago). As a sysadmin you can always decide to stick with an old version if that is what the environment you operate in demands. I think this proactive mentality of OpenSSH is an important part of their success and why it has such a good track record from a security point of view.
- xoa 10y ago
  I disagree with bandrami in this case, but I don't think this is quite right either because you focused on an instance-specific goal rather then universal principle: >As a programmer you have the right (or maybe even obligation?) to write secure software and I would argue software that's hard or impossible to use insecurely. There is plenty of software where secure usage is not a concern and that's fine. Rather, it would be better to say that as programmers we have the job to ensure that our software is as fit for primary expected purpose as possible, and in particularly lacks any surprising gotchas. Sometimes within a given program's core purpose there are decisions that can only be properly made as part of deployment/usage and those are appropriately left to the sysadmin/user, but if something is directly contrary to core purpose then it's always worth questioning whether it needs to change. In the case of OpenSSH in particular the core purpose is in fact secure links. We've all long had an insecure very fast virtual terminal system if we wanted it and it's called Telnet. There is no reason that any available built-in mode of OpenSSH crypto should ever be insecure. Asking to have obsolete methods generally considered to no longer be reliable to be "left up to the sysadmin" would be like asking it to have rot13 as a sysadmin option: completely contrary to the purpose and expected function of the program. Not just in security but in software in general any extra switches carry both developmental load (more code to go wrong), deployment load (more possibilities to make mistakes) and cognitive load, so they should always be considered to have inherent negative value and then asked to justify themselves, not considered to stick around forever by default.
  - bandrami 10y ago
    Deprecating ciphers I'm fine with. Telling me a minimum required key size isn't, because they have no idea what the window of security I'm looking for is. If I need to keep a text secure for 2.5 seconds, a short key is fine, and for that matter a longer key gets logistically problematic.
cuckcuckspruce 10y ago
It's good that you have the source code so you can re-add/maintain the features you need, or can backport fixes to previous versions that have them implemented. These changes are very good for the vast majority of users as they removes two big opportunities to silently shoot yourself in the foot.
matt_wulfeck 10y ago
In principle I agree. Looking at the security patches there seems to be a few issues around this feature. My guess is that this feature is entering the "disable before retire" phase of its life.
tedunangst 10y ago
Unfortunately, sysadmins have resolutely refused to make the right choices, thus forcing the issue.
- protomyth 10y ago
  Since I bump back and fourth between sysadmin and programmer gigs, I don't get why a system admin wouldn't want a programmer to build their software with privilege separation? What am I missing? Having a secure system is a big deal for a system admin (these days the #1 deal), but at some point you have to rely on a programmer getting it right.
  - bandrami 10y ago
    Privsep is great; I use it whenever I can. I also have tiny embedded systems that don't support it, as well as containerized systems that don't need it.
    - protomyth 10y ago
      Why would a containerized system not need it? Defense in depth would be a good thing.
      - bandrami 10y ago
        Because Docker isn't running as root to begin with; it just convinces the containerized process that it is.
        djmdjm 10y ago
        You've just demonstrated that you don't understand either the goals or mechanism of privilege separation: 1) it doesn't require root and 2) it protects more than the root account.
        mrsteveman1 10y ago
        Aren't those the "unprivileged containers" that keep showing up as having huge security vulnerabilities?
AndyMcConachie 10y ago
What's your argument for keeping it in? I mean, what specific scenario do you need to account for where this is a must have?

slasaus 10y ago

> That's not really the sort of decision application programmers should be making for sysadmins. As a programmer you have the right (or maybe even obligation?) to write secure software and I would argue software that's hard or impossible to use insecurely. It should live up to the standards of the time of release, not the time of the release of the first version (in case of OpenSSH that would be more than seventeen years ago). As a sysadmin you can always decide to stick with an old version if that is what the environment you operate in demands. I think this proactive mentality of OpenSSH is an important part of their success and why it has such a good track record from a security point of view.

xoa 10y ago
I disagree with bandrami in this case, but I don't think this is quite right either because you focused on an instance-specific goal rather then universal principle: >As a programmer you have the right (or maybe even obligation?) to write secure software and I would argue software that's hard or impossible to use insecurely. There is plenty of software where secure usage is not a concern and that's fine. Rather, it would be better to say that as programmers we have the job to ensure that our software is as fit for primary expected purpose as possible, and in particularly lacks any surprising gotchas. Sometimes within a given program's core purpose there are decisions that can only be properly made as part of deployment/usage and those are appropriately left to the sysadmin/user, but if something is directly contrary to core purpose then it's always worth questioning whether it needs to change. In the case of OpenSSH in particular the core purpose is in fact secure links. We've all long had an insecure very fast virtual terminal system if we wanted it and it's called Telnet. There is no reason that any available built-in mode of OpenSSH crypto should ever be insecure. Asking to have obsolete methods generally considered to no longer be reliable to be "left up to the sysadmin" would be like asking it to have rot13 as a sysadmin option: completely contrary to the purpose and expected function of the program. Not just in security but in software in general any extra switches carry both developmental load (more code to go wrong), deployment load (more possibilities to make mistakes) and cognitive load, so they should always be considered to have inherent negative value and then asked to justify themselves, not considered to stick around forever by default.
- bandrami 10y ago
  Deprecating ciphers I'm fine with. Telling me a minimum required key size isn't, because they have no idea what the window of security I'm looking for is. If I need to keep a text secure for 2.5 seconds, a short key is fine, and for that matter a longer key gets logistically problematic.

cuckcuckspruce 10y ago

It's good that you have the source code so you can re-add/maintain the features you need, or can backport fixes to previous versions that have them implemented. These changes are very good for the vast majority of users as they removes two big opportunities to silently shoot yourself in the foot.

matt_wulfeck 10y ago

In principle I agree. Looking at the security patches there seems to be a few issues around this feature. My guess is that this feature is entering the "disable before retire" phase of its life.

tedunangst 10y ago

Unfortunately, sysadmins have resolutely refused to make the right choices, thus forcing the issue.

protomyth 10y ago
Since I bump back and fourth between sysadmin and programmer gigs, I don't get why a system admin wouldn't want a programmer to build their software with privilege separation? What am I missing? Having a secure system is a big deal for a system admin (these days the #1 deal), but at some point you have to rely on a programmer getting it right.
- bandrami 10y ago
  Privsep is great; I use it whenever I can. I also have tiny embedded systems that don't support it, as well as containerized systems that don't need it.
  - protomyth 10y ago
    Why would a containerized system not need it? Defense in depth would be a good thing.
    - bandrami 10y ago
      Because Docker isn't running as root to begin with; it just convinces the containerized process that it is.
      - djmdjm 10y ago
        You've just demonstrated that you don't understand either the goals or mechanism of privilege separation: 1) it doesn't require root and 2) it protects more than the root account.
      - mrsteveman1 10y ago
        Aren't those the "unprivileged containers" that keep showing up as having huge security vulnerabilities?

AndyMcConachie 10y ago

What's your argument for keeping it in? I mean, what specific scenario do you need to account for where this is a must have?