151–160 of 192 posts
Earlier quoted context omitted.
When I did my first github "release" I was shocked that it involved picking files to upload...
And how many of these files have I downloaded over the years? :sob:
"Could have" means unproven here, and actually... They shipped it
the article demonstrates how to imorove NixOS (or Guix) to automatically catch any such discrepancy in the future.
Note that NixOS and reproducible builds did not detect the xz backdoor, and in fact NixOS shipped the malicious builds of xz (though they didn't do anything because the malware didn't target NixOS): > I am a NixOS developer and I was surprised when the backdoor was revealed to see that the malicious version of xz had ended up being distributed to our users. As always theory and reality are different, and the thing th…
> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…
You would essentially need Android or iOS for it to not be a pain in the ass
Nonetheless, in this year and age this should be the bare minimum from a security point of view.
[flagged]
I generally believe that NixOS is less secure than some other systems. No secure boot by default, no SELinux, too few maintainers for a huge package set, and relatively easy to gain commit access.
But it does have a lot of other benefits.
Earlier quoted context omitted.
> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…
> including no access to ~/ This is such a headache with snap and flatpak though. If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges". Some examples of sandboxing issues: * F…
> let's make it easy for users to break programs out of the sandbox when it suits them?
At least for Flatpak given the things you described this is quite straightforward via bind mounts. Although it did seem a bit goofy having an entire list of per-application bind mounts in my fstab. Maybe things have improved since I last tried going that route?
> "idiomatic" ... doesn't use a file dialog,
That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals for all supported operations at this point. The only excuse (IMHO) is for missing or broken functionality.
It would be like a system tray widget not working and blaming the DE instead of the program that fails to implement the decently old and widely adopted standard.
> Matrix ... you can't share any files with anyone
Which client is this? Anyway the xdg portal should work. Did the dev try it? Programs should never need blanket access to save or open specific user supplied paths as a one off. That's a large part of the point of sandboxing stuff in the first place.
NixOS is really irrelevant here because the xz backdoor specifically targeted RedHat and Debian. It's equally relevant to say the xz backdoor didn't affect Windows (ironically the backdoor was ultimately found by a Microsoft employee, an oft-overlooked detail).
a slightly improved version of NixOS (or Guix) would have automatically caught this backdoor once it reached their repos. they are relevant.
Excellent descriptive analysis. Wrong, misleading title, perhaps "technically correct," but at best with a "backdoored" meaning. It points out the need and use for build-manager tools that go a step beyond union file system layers, but track then enforce that e.g. tests cannot pollute build artifacts. Take a causal trace graph of files affecting files, in the build process, make that trace graph explicit, and then bu…
[flagged]
Earlier quoted context omitted.
> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…
Such sandboxes would only work well , if the whole OS would be built around supporting them. You would essentially need Android or iOS for it to not be a pain in the ass Nonetheless, in this year and age this should be the bare minimum from a security point of view.
Earlier quoted context omitted.
> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…
> including no access to ~/ This is such a headache with snap and flatpak though. If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges". Some examples of sandboxing issues: * F…
As a user, I quite like the iOS approach, of apps "sharing" their ressources with other apps or asking for permission to access this or that collection of ressources. This can probably be improved and adapted to a non-touch model, but I think the concept is nice.
But, of course, apps have to be built for this kind of environment, so I think there will unfortunately be some janky transition period, with the customary competing, incompatible implementations.
Earlier quoted context omitted.
>You can often only drag 'n drop from ~/Downloads/ Drag and drop could be made to always work since it's being done by a user. Request this feature from your operating system's developer.
Is it? There is such a thung as GUI automation. It's not a very popular exploit vector because it is visible, and because there are simpler non-GUI exploit vectors available. But nothing fundamentally stops an attacker process from pretending it's accessibility software and taking control of the mouse to do a drag-n-drop.
That should be a privileged status. If you manage to trick the user into installing malicious software followed by granting it elevated privileges then you likely didn't need such a roundabout method in the first place.