how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
131
Replies
·
0
Boosts
ok so they decided to reinvent sudo for sshd root https://github.com/openssh/openssh-portable/blob/master/README.privsep if i cannot disable the sshd build (reading ./configure --help in a crazed demented rage did not see the flag for it) i'm going to commit several murders
how do you spend 8kb of text and provide multiple detailed ASCII art diagrams regarding your privilege separation methodology and oh my god wait does it really require sshd to be root too yes it literally does are you fucking kidding me
this is so fucked
sshd is the main entry-point binary for the server. This binary retains privilege but performs a very limited set of tasks: loading and checking the configuration, listening for incoming connections
and monitoring the status of connections through the pre-authentication phase of their lifecycle to implement the MaxStartups and PerSourcePenalties features.
NONE OF THESE THINGS REQUIRE ROOT WHAT THE FUCK
@hipsterelectron Maybe I'm VASTLY missing the point here, but doesn't listening on port 22 require root, because 22 is a privileged port? Isn't there a tradition of servers being forced to use root on linux for this reason even if they don't need it for other reasons?
@psf yes and another example of linux being the problem here is in requiring root for the very chroot call that is used to perform the "privilege separation", making that linux decision by itself necessary for sshd to run as root
@psf i am but a humble build engineer and i wish only to build git and its deps from source and openssh is giving off incredibly fucked vibes
how is anyone ok with this????? it takes half the document and two fork/execs before it gets to why sshd-auth would need root:
All operations that require privilege, such as looking up user information, private key signatures, checking passwords, etc are performed by RPC to the parent sshd-session process.
- looking up user information????????
- i think you can calculate cryptographic signatures without root????
- the fuck do you mean """"checking passwords"""""
i have been informed that even looking up the list of users requires root and have concluded that the unix user model is well-designed to suit the bell labs HR system from the 1970s and was never a serious general permissions model
https://github.com/openssh/openssh-portable/blob/master/LICENCE
i have never seen a stranger license file in my entire life. they also spell the filename in a way i have never seen before
Some code is licensed under a MIT-style license to the following
copyright holders:Free Software Foundation, Inc.
that's not even legally binding and obviously intended as an insult. they also mixed spaces and tabs in indentation???
@hipsterelectron this whole file looks like some sort of experimental poetry..
https://github.com/openssh/openssh-portable/commit/7294baaf6ab389fd206899d68a1ad400ba2f4508
- (djm) Forgot to cvs add LICENSE file
first of all, what a remarkably specific commit description. second of all, that's not worth a ChangeLog entry. third, it's not named LICENSE?
i didn't peruse the whole contents of the LICENCE file because the file being 300 pages long and under a nonstandard filename without symlinks tells me that this is an incredibly politically motivated project. i wonder if that means they're left-wing!
it takes a certain kind of person to use "portable" while using fucking autoconf and then stuffing the LICENCE file with actively contradictory statements
oh and there is a single very clear and absolutely legally actionable statement at the beginning of the LICENSE
Any derived versions of this
* software must be clearly marked as such, and if the derived work is
* incompatible with the protocol description in the RFC file, it must be
* called by a name other than "ssh" or "Secure Shell".
"Any derived versions of this software must be clearly marked as such" is completely incompatible with publishing it via git, but i think that's intentional and it just serves to sound vaguely legal so the line after it sounds legally actionable
that is fucking bizarre. it's also incredibly strange to assign copyright to a single person in the first place. who the fuck is tatu ylonen
https://fi.wikipedia.org/wiki/Tatu_Yl%C3%B6nen english wikipedia has no page on him but i believe finnish wikipedia says he invented ssh. however his own website https://ylonen.org/ then clarifies he wrote "the original ssh" but not openssh which should be sufficient evidence to void his copyright claim over any of the code at all
@hipsterelectron i would have to check, but i think openssh was either a fork of the last permissibly-licensed version or a reimplementation of the protocol. it was quite a long time ago, though you might find closed and archived debian bugs related to the issue.
if you look at the rfcs for the ssh protocol version one, i'm quite sure you will find tatu ylonen as the document author or at least co-author.
as usually with weak copyleft, the whole thing was a mess.
so the actual ssh guy absolutely does incorporate gnu code (i literally bet it was readline) and then this openssh "portable" fork uses his name to scare people while systematically replacing every single gpl dependency. i wonder if they were motivated by the common good!
I'M SO CONFUSEDDDDDD https://github.com/tatuylonen/tokentree/blob/master/tokentree/ctokentree.pyx
- this would literally be easier to read and fewer lines of code to do in C than in the OG slop python c compiler?????
- the entirety of
_add_{with,no}_extra()is repeated??????
# Increment the count of all nodes (doing this here in between
# seems to improve performance by about 5% - probably due to
# memory latencies)
who is this for. who are you doing this for dude
looked up the OG slop python c compiler to see if it would summarize its theory of operation in the README https://github.com/cython/cython it absolutely does not but it does the exact same fucking thing with the obsequious false deference to the "original author" of a completely separate work
python has one of the nicest build systems and tooling for c extensions i have ever used for any FFI and unlike the python language itself the C ABI has extremely well-defined stability guarantees. furthermore this is one of the many tasks that c is good at and python itself makes inordinately annoying.
his website points to https://www.ssh.com/academy/ssh under the title "original ssh", the one he says he wrote, and then that page says he's on twitter and links to https://x.com/tjssh, which has absolutely zero posts but follows more people than i did when i was on there.
so, this guy clearly doesn't exist, or perhaps he died. let's take a look at his rfc history (????)
i notice he literally has all the standard NSA track publications in database design https://ylonen.org/ but then he describes something called "shadow paging" which seems ridiculously similar to my architecture for i/o scheduling
the last time this happened was when i read about alexia massalin's synthesis kernel who also disappeared suddenly around the year 1995 after developing a more efficient chip fabrication technique
unfortunately for my preconceived notions this 2015 NIST document on ssh security is remarkably well-done https://nvlpubs.nist.gov/nistpubs/ir/2015/nist.ir.7966.pdf this paragraph is a fucking banger
Generally it has been found that the cost of manual labor in a key management project is often as big or
even significantly bigger than the cost of the tools for managing the keys. The choice of tools has a major
impact on the amount of manual labor needed.
also stealing this bit from his phd thesis for my phd thesis and adding 40 years
7.2 The Impact of Technological Development
The cost of main memory has dropped dramatically since the rst half of 1980's, when most performance comparisons between shadow paging and logging were made. It is now reasonable to assume that in most applications the entire page table of even a fairly large database will be available in the cache most of the time. Even for very large databases, those parts of the page table which are used frequently will remain in the cache. This has removed the most serious performance problem with shadow paging.
much of the thesis is really boring and uninteresting to me because i do not have the patience to optimize things without upsetting the balance of power. but i'm super glad i looked at the section on snapshotting and dumping because who doesn't love taking dumps
it also provides this SUPER fucking useful line
A snapshot is a transaction-consistent1 copy of the database [1].
[1] Transaction-consistent means that all transactions are either fully re ected in the copy, or not at all. No effects of uncommitted or aborted transactions will be visible in a transaction-consistent copy.
cc @zwol this is from https://ylonen.org/papers/lis-thesis.pdf and to me it produces a wonderful argument: how on earth can you even define a backup without formalising state consistency with something like a transaction? how many backups describe a state that never actually existed on disk because of modifications during the time between the start and conclusion of the backup?
i'm literally sooooooooooo scatterbrained bc i had never in my life really understood the point of a filesystem snapshot except like to restore files that were accidentally deleted but lmao of course snapshots are exactly what git ostensibly records for changes to a filesystem tree
if your filesystem is not like used by a real human being to organize their cute little files while naming their adorable little directories and is instead the input and/or output of a process (probably just the input actually) yes of course you want snapshots
@dragon which do you think is cuter files or directories. i think symlinks are cute but very mysterious and sometimes they can get lonely
i also still have the correct belief that hard links to directories make perfect sense and everyone in the world is wrong about this because you need inodes with hard non-recyclability guarantees to avoid checksumming the same massive file 300 times in a row anyway and there's no way every c programmer ever hasn't wanted this
not the "hard links to directories" part that's a super specialized use case
@hipsterelectron the original author of the protocol and first implementation, if memory serves.
@hipsterelectron under Linux at least, getting a list of users on the system does not in fact require root
@freya i was told /etc/shadow requires root and that it performs password auth by checking that which seemed roundabout and when i remembered su exists i decided this was a remarkably strange decision indeed. i have decided the other reasons are also wrong but after a friend was confusingly hostile to me i have decided not to share further thoughts about this system to fedi.
meanwhile i will probably have to patch the codebase in a complex way that will produce constant merge conflicts if i want to achieve the thing i was trying to do in the first place, which was to build the ssh client and not the server.
i wouldn't have noticed anything in the first place if this wasn't the first package i've ever seen that produced a permissions error from the spack sandbox. i don't understand how
@hipsterelectron /etc/shadow requires root but /etc/passwd does not
@freya this is actually just because i wanted to build git+deps from source and i am constantly upset about how git is not actually a state tracker but the answer is so slippery in my head every time i try to grasp it
@hipsterelectron checking passwords for password auth requires reading /etc/shadow, which is restricted to root only
the private keys are stored under 600/rw------- perms by each user so other users can't read their keys. hence root is needed to access them
@hipsterelectron also listening for connections does require root since port 22 is root-only due to being <1024
@lunabee this is the least legitimate reason imho because you should be able to choose whatever port you want and furthermore any OS enforcing the 1024 port root rule is making users do a privilege escalation for absolutely no reason
@hipsterelectron yeah it's a known problem. legacy from back when people trusted sysadmins arbitrarily
but ssh isn't the kernel or posix standard so
they kinda need to
@lunabee IETF standards are more obviously backdoored than POSIX, which is less obviously backdoored than the kernel, and ssh -p selects an arbitrary port, as i am confident you are already aware. i do not remotely understand the "need" you are describing
@hipsterelectron bestie do you know what ssh, like, is
@haskal i thought it was an RPC protocol
@haskal every single one of these things is required for accepting ssh connections with sshd, which is a ridiculously specialized use case that is well-understood to expose you to attack. i can therefore understand some degree of complexity in their protection mechanisms. what i don't understand is why it would not be made painfully obvious how to build just the client program and not avoid having to incur any of this in the first place
@hipsterelectron one way to log in 2 ssh is with a username and password. that's what is meant by looking up user information and checking passwords
@haskal thanks to @lunabee i have aged 500 years in an instant https://cathode.church/@lunabee/116965608768380463
@hipsterelectron @lunabee okay? uninstall ssh then. you can authenticate to your computer over the network via uhhhh ummmmm uhhh well im sure you'll figure it out
@haskal i did not intend to insult you and i'm sorry. you also described exactly the same thing and crediting her was not intended to dismiss your very patient responses. i thought i had made it clear my goal is just to build/install the openssh client and not the server and it's really annoying they don't consider that an obvious thing someone might want to do. i am surprised at each one of the sshd-auth operations indeed requiring root, all of which have exposed to me new details of the unix security model. i do in fact appreciate you spending the time to teach me that.
@hipsterelectron changing user to the target user after login requires root
