If something works as intended, but its utility is limited, and it can be improved, it is not broken.
You can play with your words and redefine their meanings, but the vulnerabilities remain.
I don't think OP was trying to play with words, I do think there's an absolute "this symlink thing is a vuln" vs an absolute "I use symlinks to make X work" argument. Symlinks have always been at the line between the absolutes. They do enable a great deal of functionality but they can be a security risk, and source of bugs when developers don't handle them correctly. That said, they are heavily used feature on unix like oses. My /usr/bin on Ubuntu has 48 of them (most were put there by apt installed packages).
There is no otherwise! POSIX has symbolic links: if your software does not function with symbolic links, it does not function on POSIX.
Can you not imagine anything other than POSIX?
No, bad coders on UNIX platforms do this.
The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022.
Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
Programmers aren't using them because the language standard libraries point them in the wrong direction.
[0] https://github.com/google/guava/wiki/Release21#user-content-... [1] https://github.com/rust-lang/rust/blob/1c63ec48b8cbf553d291a...
But it wasn't. It followed on from Win16 and DOS so, to an extent, it emulated DOS-style path and file handling. After all, that's what developers and users were familiar with. The Windows registry did not have all this baggage so it followed the style of the NT kernel.
Though this doesn't explain why Win32 never added CreateFileRelativeToDirectoryHandleW
Frankly blaming the kernel/filesystem for this is like saying I want my 720p monitor to display 8k correctly, it must be the display-drivers fault...
Do you really think that using open(), stat(), lstat() (!), realpath(), mkdir(), rename() etc etc etc is a sign of a bad coder? The problem is that the APIs set you up for unexpected failure, and even some of the provided workarounds to 'safely' handle symlinks don't do it well enough.
In the case of symlinks, I think it's fair to blame the tools rather than the workman.
Example: wanna show 1M POI in browser on some small territory. Openmaps/googlemaps API allows that, no prob. Looks good, yeah? Sorry, doesn't work. Because 1M is too large to show and browser gets stuck.
The API do not prevent _all_ kinds of legshooting engineers invent.
Most sane languages and low level tools describe what you want and how to work correctly.
If you don't want this feature in the filesystem, move to one that doesn't support it, or better yet submit a patch to run the filesytem you want with this feature deactivted for "security concerns".
Demanding a whole OS change the way it works for bad/lazy/inept coders is akin to 2 people getting blind drunk and blaming the other person or the drink for the stupid things they did. Take some responsibility.
And if people were just more careful, none of rust's memory safety stuff is needed! Also, why do modern languages hand hold multi-threading so much, just give developers some mutex primitives and let them have at it, the good coders will be just fine!
Of course the rest of us will have to deal with machines getting pwned due to security bugs, but hey, at least the "well written" programs won't have those problems...
Everything you're saying is an excusory situation for hiring poor coders at minimum wage who can't or won't read documentation. This is 80IQ points South of frankly most of the conversations on here.
Yes the rest of us cope with security incidents. There will always be security incidents. Stop defending practices that leads to them.
This is a hopelessly elitist attitude. Also it is a useless one, over 1000 CVEs, yelling "be better at your job!" is just going to result in another 1000 CVEs. That is exactly what happened for decades with buggy C code, buffer overflows and use after frees, for a long time the refrain was "just do better!".
Well millions of dollars of damages later, it turns out berating people to "just do better" doesn't actually make things any better. A combination of static analysis and runtime tooling, and then the eventual creation of new programming languages that allow for correct modeling of memory ownership, is what the industry en masse has decided on.
For APIs that get misused? The solution is to provide higher level APIs that allow programmers to easily accomplish the correct thing in a secure manner.
As an aside, and in general, when designing software, I want to maximize the amount of brain power I am dedicating to solving the business problem at hand. Dealing with poorly designed insecure APIs detracts from me getting my actual job done.
> Stop defending practices that leads to them.
The practice in this case is the direct use of filesystem APIs that were designed in the 1970s for a very different security ecosystem than what exists today.
Lots of things designed in the 1970s are not secure by default. Heck most things designed in the 1970s, outside of maybe some IBM Mainframe stuff, was not designed to be secure by default.
What you are arguing is that instead of buying a fire extinguisher to put in the kitchen of an old house, people should just try and not set things on fire.
I mean, yeah, sure, good goal, but buy the fire extinguisher anyway.
My whole point is the same as yours fix it at the source. You seem to think hacking off the hands of some coders is safer (I may agree). But why not try to EDUCATE THEM?!?
Education costs 1000s of dollars at most rather than your hypothetical billion dollar APPLICATION LEVEL hack.
Why are you so elitist to assume people can't cope with these concepts?
My whole point is that they need to be tought they're running on a Unix server rather than an 1998 SD card. The rest of your complaining is either you don't understand this or are trying to excuse bad or insecure practice as acceptable. If this is your case. RUN THE CODE IN AN ENVIRONMENT WHERE THIS CAN'T HAPPEN. Seriously there are filesystems and options for this.
Calling for these features to be removed from extX, ZFS or other shows you don't understand storage technologies well enough.
If a lot of code, written by a lot of different engineers, all ends up being insecure, it is worth asking, why is code dealing with this particular domain so often insecure?
> But why not try to EDUCATE THEM?!?
You can do that, and of course we should, but here is the thing about security:
The good guys have to write secure code every time, or else the attackers guys win.
Eternal vigilance is inhumanly hard to maintain. A better solution is to write higher level APIs or API wrappers that don't have these flaws.
> Why are you so elitist to assume people can't cope with these concepts?
Sure they can, but how many concepts can people cope with at once? Humans have a limit for how much they can juggle in their head. A huge part of software engineering is picking what abstraction layer to operate at. If I am writing code that deals with tons of string parsing and manipulation, I'd be a fool to write it in C or C++. Now I've done that when I needed the performance, but managing a massive number of strings in native code is easily 5x the work compared to using a GC language that also automatically tracks string length.
C is the wrong abstraction there. And indeed an obscene number of security holes have historically centered around string processing in C. That is because on top of managing all the business logic (which may be obscenely complicated by itself!) engineers now have to do so in a language that is really bad at dealing with strings and they have to do a lot of mental work to ensure the code is correct.
If I am manually flipping bits in hardware, well, JS can do it (I have seen it!) but honestly, that shouldn't be anyone's language of choice for directly interfacing with hardware.
(Doing that in C, really fun!)
> Calling for these features to be removed from extX, ZFS or other shows you don't understand storage technologies well enough.
I am not saying that. I am saying that the original POSIX APIs make writing secure code around symlinks hard, and I am saying that solely based on the fact that a bunch of security holes around POSIX APIs and symlinks exist!
This isn't some shocking statement. The original POSIX APIs make a lot of things hard.
If you want this level of abstraction it should be built into the framework or language you're using. I'm not saying go away and rewrite chrome in C you'd be chasing segfaults for 5 years.
If you want to hire people who don't care again. Run this in an environment where this doesn't matter. If you're ultra paranoid insist in a layer to compensate for people's failings.
Again there is nothing wrong with the tried and tested API that can't be fixed with a modicum of effort. Calling it broken or insisting it change to fit problems caused by people so far removed they don't know what architecture they're working code for is not a reason to change the POSIX system. It's a reason to fix your abstraction.
Write an abstraction on top of the hard to use API for the majority to use, and people who need to use the low level API directly can learn to do so.
You characterized people who write code with security holes as "stupid/lazy", that is elitism.
About ~10 years ago, a lot of databases used to ship with no PW on by default. This lead to a lot of information disclosures as people new to the cloud based world setup a DB and all of a sudden it was world readable with no authentication needed.
When this happened, a bunch of experienced DBAs started saying the problem was mass incompetence on the part of these "young developers who think they know how to be a DBA." Their proposed solution was for companies to start hiring "real DBAs".
The actual solution was to have databases not allow exposure over a public IP unless a password is set, which is now the default on the vast majority of databases, and when it isn't, there are giant warning banners that flash everywhere alerting developers to the giant security hole they are about to deploy.
I'm not saying elitism is always bad. Those DBAs who understand exactly how query optimizers work and exactly how databases store everything under the hood are needed, just as the developers who know the detailed ins and outs and proper usage of low level operating system APIs are needed.
But if a lot of otherwise capable developers keep making the same mistake using some tool or API or cloud service, instead of trying to assign blame to individuals for being stupid or lazy, we as an industry should instead ask ourselves why so many people are having the exact same problem.
I'm elitist about plenty of things, and it took me time to realize that just because I know the "best" or "correct" way for something to be done, doesn't mean that everyone else needs to do that thing in the "best" way.
Anything in this world meant for usage by a large number of people, a product, API, flat packed furniture, setting up a printer, needs to cater to the needs of the job that people want to get done. Saying people are "doing it wrong", well, at best that approach gets companies put out of business (see: Everyone selling smartphones who wasn't Apple/Google), and at worst the harm can be magnified many fold.
In fact, computers are probably the only place in the entire technology landscape where we keep using almost unmodified stuff from the 70s and decided we cannot change it because there's too much things relying on it.
I don't like breaking everything all the time more than anyone, but maybe one time every 20 or 30 years is OK…
Bridges and buildings from the 1970s (and much older) are still working fine today.
The thing is, if I do decide to replace my bridge or building because it's old and outdated then I can just replace that one thing without affecting much else. With computers, that is obviously not the case: you need to replace the entire city.
Plus, it's not really the case that we "keep using almost unmodified stuff from the 70s"; while many concepts remained the same and things remained compatible, things have been greatly extended and modified since; it's like those old buildings that were built during the middle ages (or sometimes even earlier) that have been changed and upgraded extensively throughout the centuries to the point you really need to know where to look to see it's actually a centuries-old building.
With modern earthquake straps added, and I bet the locks got replaced a few times over, also the building likely had its insulation improved, better venting added, a sprinkler system, fire exits, and a wheelchair ramp put in at some point.
Are there a few quaint stone bridges from 1700 still in use? Sure, going over the neighborhood creek. But all the bridges around me have undergone serious upgrades or retrofitting over the decades.
I am not sure about that, floods here go past the 200 years average line at the time that many bridges or buildings was designed. And actually breaks a lot of buildings.
Climate change these days is just as unexpected as hackers these days to who we were.
Not just one city needs the upgrade, all of them will need it, and all the related infrastructure like bridges and tunnels too.
It's kinda mainly desktop/server Linux where there's this inability to move forward.
A better example would be Apple which makes breaking changes to both iOS and macOS absolutely all the time.
I'd argue that it is.
I would probably draw a line between writing and vernacular speech, in the sense of language acquired simply through assimilation and not specifically trained or drilled.
There might be writing which fails that test (e.g., very basic literacy), and of speech which passes (advanced rhetoric, debate, accents and impressions, singing, etc.).
But as a socially-acquired means-to-an-end refined by practice and study, yes, technology.
When I'm exposed to a core OS feature I expect by default that it should not come with expected, critical security vulnerabilities. It is rational to expect a user to use the basic features of an OS and expect them not to cause severe issues. You can say it's not broken, and that's true in as much as they're still functional, but if by broken one means the larger question of "is this reliable and safe?" then I think the answer is pretty clear that symlinks are broken.
It's important to understand the scope of the issue. If you create and operate on your own symlinks in your own folders, there is no problem. The problem is when a more privileged user operates on folders that can be written to by less privileged users, for example system daemons (like a /tmp cleanup, or a web server serving /home/*/www), or suid binaries. These things need to be written very carefully, it is now clear.
But if I'm working with my own files, media, source code, build tools, web pages, etc, in my own folders, then symlinks are still fine.
And there is an existing setting to mitigate a couple common forms of the issue that does exist when accessing folders other users can write to: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs...
The problem is that there is such a huge number of tools in widespread use that each one causing even a few security vulnerabilities means that the ecosystem overall is constantly vulnerable
Could we consider it a broken doorknob Pierce?
Or, more like, if there's an attacker hiding in your house, while you're setting up the shoelace door thing for some odd reason, they could slam the door on your fingers. Oh no, how were we ever allowed to have doors, so criminally unsafe.