On 6/19/24 00:42, 4 wrote:
On Tue, Jun 18, 2024 at 4:14 PM 4 <ba...@yandex.ru> wrote:
i'm sorry, i'm not smart, but i have a several questions. imagine
that we launch a ship far into space. we have only one
communication channel with this ship, and one day, when the ship
is already very far away from us, communication channel stops
working [...]
You did something wrong. It's pretty apparent from the tone of your
message you don't want help identifying what it was or how to fix
it, but for the benefit of others who find this thread in the
future, read the sshd_config man page to find out how to use the
ChrootDirectory option correctly.
i'm not talking about how to properly use chroot, but about the fact
that sshd refuses to launch because /var/empty has "too many rights".
You seem to fail to understand one of the basic goals of OpenBSD:
security through correctness.
Your starting example (spaceship communications) is the an example of
"Fail Open" -- when things go wrong, you want to be able to retain/regain
control and fix the problem. (It is also an example of "embedded
systems" programming, where faults just aren't supposed to happen. But
it also mandates very simple and verifiable code).
OpenBSD is very much a "Fail Closed" design.
If someone is storing your personal information on an OpenBSD server,
and that server is compromised, which would you rather happen?
1) system continues to operate as best it can?
2) Shut down, panic, stop doing whatever it was doing that allows
your data to escape?
You clearly think option 1 is the preferred choice. OpenBSD developers
(and I) prefer option 2.
Let's look at /var/empty, which you are so upset about.
That's not a storage location. As the name implies, it is intended to
be an empty directory. The sshd process is chrooted into it. It isn't
just your sshd's home directory, it's its entire existence. If something
goes wrong with sshd, we want it confined within a space with no files,
and a space it can't create files and can't wander out to the rest of
the file system. If someone finds a way to "break" sshd, the first hope
and first line of defense is it should crash and just kick the user out.
Failing that, we don't want the attacker to be able to wander the tree
or create files.
Back to your spaceship example...if at launch time, the control systems
detect the fuel tank is full of LOX, the LOX tank is full of fuel, and
one of the side boosters is mounted upside down, what do you want to
happen? You seem to advocate yelling, "You only live once!" and hitting
the launch button. Again, that's not the OpenBSD way.
I do believe an OpenBSD developer once took great pride in how UNSTABLE
the OpenBSD kernel is. The code has a path it needs to follow, deviate
from that path, and things get killed. Deliberately. By design.
Because...the code shouldn't have done that, and if it isn't playing
by the rules anymore...it needs to die because it can't be trusted.
Uptime is good. Security is good. Most people say, "Security is most
important!"...then start listing the exceptions. "high uptime" "Run
my favorite poorly written software". So really, security is the least
important consideration. You want to be able to break your system and
repair it over the network without console access. To your credit, you
are honest about that. That's your call, but you are gonna want a
different OS. Perhaps Windows 95 (remember the user name/PW prompt,
where if you just hit ESC, it went away and dropped you at the desktop?).
OpenBSD is probably not the tool you want.
Nick.
