271–280 of 316 posts
Earlier quoted context omitted.
Agreed. This problem exists because someone wrote a tool that should only do one (really well) and but instead made it do five different things.
According to you. I appreciate that TextEdit is a rich editor. I can use vim or countless other apps for plain text. Few do what TextEdit does with its simplicity.
Earlier quoted context omitted.
perhaps this is the worst possible abstraction to be protected by a security framework.
I don't think "everything is a file" is necessarily bad. What's worse is "every application I run has access to every resource that the OS gives my user access to". Would be nice if the operating system could set up a fresh, temporary "user" for each application installed, and instead run the application as that user, who starts out with no access to computing resources. Maybe some existing systems already sandbox ap…
But often when such sandboxes are attempted, it turns out that it often became more complex than originally thought, and applications need many resources which were not originally considered, so they are given those resources, and very often those resources can be used again to construct more resources or otherwise to some measure escape the sandbox.
FYI: The year part of a CVE ID is either when the ID was assigned or when the issue was publicised: https://cve.mitre.org/about/faqs.html#year_portion_of_cve_id
Not (as I had assumed) when the vulnerable software was first published.
File extensions are a kludge anyway. (And Windows 10 still hides them by default, because hey, backwards compatibility, and you wouldn't want to confuse Grandma who's seen the file be called "grandkids" since Windows 95..). Why should the filetype be dependent on the name? People even think renaming a .BMP to .JPG means now it's a compressed file! Old school Macs stored the filetype outside of a file, so you can rena…
I don't actually think file extensions are such a bad system. Filenames exist to provide context for the data inside. "Draft 2020 Quarterly Report.txt" and "Draft 2020 Quarterly Report.csv" could contain the exact same data, but the file extension indicates how the file is intended to be used, just as "2020" indicates the relevant year and "Draft" indicates completeness.
Oh, man. The idea that TextEdit automatically parsed .txt files as HTML if they started with a certain file signature is problematic... ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those. The fact that a Mac engineer thought it woul…
Earlier quoted context omitted.
“Everything’s a file!”
> “Everything’s a file!” I fail to see how HTTP and REST's "everything is a resource" paradigm is significantly different than UNIX's "everything is a file" paradigm, and I'm yet to see anyone claim that the freedom and power to open any HTML document (OMG a file!) made available through the internet is a mistake or a bad design decision.
On the other side Unix has users and permissions, HTTP does not and you have to build your own.
Earlier quoted context omitted.
I don't know what people expect - don't run code you don't trust. There is also lots of ways for python to leak data if you execute a malicious python script.
It's not about running code, it's about opening a TXT file with the operating system default handler for TXT files. So you what you are saying is basically 'do not open any files or websites you don't trust' - which is usually not what people expect as that would basically mean 'don't use your computer'
Earlier quoted context omitted.
If you follow the everything is a file philosophy it seems quite natural does it not?
Except permissions aren't granular enough / are too confusing, it's a giant footgun with the current Linux architecture, which doesn't have all the nice things Plan9 does
Earlier quoted context omitted.
> ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. Not that shocking. Windows has had that with SMB networking for ages file://SMBSERVERNAME/path/file . Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly.
SMB is more understandable though, since you have more trust for things on your local network, and an attacker usually won't have control over those resources. And it's a fairly common and reasonable expectation in a business environment that network drives appear as part of the filesystem. Whereas a domain name over the open internet is an entirely different story.
Earlier quoted context omitted.
An example of "unsafe defaults:" NeXT used Display PostScript for the display manager. If you opened an email that had PostScript commands, the mail agent would happily, automatically, execute them. A favorite payload sent around the computer lab would smear all pixels downward to "melt" whatever was rendered on your display. Note that there weren't that many interesting things to exfiltrate back then, so this wasn't…
You don't need a password to be echoed to exfiltrate it. You just need the key codes. Not sure about NeXTStep, but regular old X let you sniff keys really easily. Some systems (specifically, earlier versions of SGI IRIX) shipped with X authorization disabled by default. This is the equivalent of "xhost +". You could sniff a box as soon as it was plugged into the network, including capturing login session credentials,…
Do MacOS and Ubuntu ship with firewalls?