41–50 of 117 posts
If Linux ever becomes useable for the average consumer and its adopted widely, we will see plenty of viruses for it.
I'm more optimistic about systems like Fuschia which are capability-based from the kernel up.
Earlier quoted context omitted.
As if a virus really needed administrator access for anything... Maybe to fuck up your machine... but if they want to snoop on your passwords, encrypt your files, mine bitcoin, participate in a DoS attack... they can do that without elevating
You could even replace every command I run with a malware version simply by altering the $PATH in ~/.bashrc. If you manage to replace, say, apt-get with a malware version, you'll get admin permissions every time I run `sudo apt-get ...`.
Earlier quoted context omitted.
https://github.com/nodesource/distributions#installation-ins... I'm sure there are plenty of others.
At the risk of appearing ignorant.. what exactly is the problem here? Do we trust the nodesource deb repo but we do not trust the bash script which is coming from the nodesource domain?
If you get MITM'd (admittedly difficult with TLS) or the site got compromised (but not the build IX / developer's keyring) it would be possible to replace the script with a malicious one.
Also, you can detect the curl|bash installation method server-side and serve different content [1] on that basis, which is not possible with deb packages.
Finally, providing a curl|bash installation method implies that the developers either do not understand packaging, or don't care about it. This is fine e.g. if developers want to remain platform agnostic or just can't be bothered packaging, but if you develop a curl|bash installer you send the message "I want to distribute my software but don't care enough to do it properly / in a standards compliant way".
Also, and this is more subjective, most curl|bash installers I've seen make assumptions about their environments that do not necessarily hold in less common distributions - which makes you wonder why they don't just develop e.g. a deb if it only works reliably on Ubuntu and maybe Debian.
[1] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
Earlier quoted context omitted.
I've definitely seen plenty of `curl | bash` installations suggested before (and can honestly say that I've run some, despite knowing the risks), but _sudo_? Is that a thing that people actually do?
https://github.com/nodesource/distributions#installation-ins... I'm sure there are plenty of others.
Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last mile, often because its a lot of boring work. Mandatory Access Control should have been game changing in the security sphere, especially in the era of cgroups. Fine grained permissions controls in the kernel and filesystem would stomp out almost all potential m…
But solutions like selinux, apparmor, and tomoyo are built on the premise that it's the user, administrator, or packager best positioned. But this is a false premise. These people are the worst positioned to understand which privileges are needed, when they're needed, and how to constrain them. They're certainly not well acquainted with the software and how it operates. The only tools at their disposal are external policy mechanisms which are often extremely difficult and complex to use to achieve the desired level of access with the external environment. And they're incapable of refactoring the target software to improve the situation. It shouldn't be any surprise, then, why these resources are underutilized.
seccomp is an improvement but it's much too low-level. Other than the obvious issues that a simplistic syscall filtering mechanisms is too brittle, seccomp 1) doesn't support file paths, and 2) the inheritance semantics makes it nigh impossible to refactor existing code which invokes other programs while 3) also setting a high bar of minimal complexity for new code. Again, no surprise why this resource is underutilized.
This is why OpenBSD's pledge and unveil are infinitely easier tools for securing programs. They were conceived and refined with the goal of making it easy to lock down programs, not to maximize purely abstract requirements like fine-grained control or administrator flexibility. And in any event tools like file permissions and other access controls remain readily available to augment the built-in privilege restraints.
Android is a poor example, especially for server systems, because Android programs don't need to interoperate directly with each other. Whereas on server systems the degrees of interoperability and dependence of various pieces of software are extremely complex and varying. One alternative, forcing everyone to write microservices, at best simply shifts the burden around; it doesn't help to minimize that burden, nor does it permit us to incrementally and organically improve the situation.
On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…
Nix/Guix are quite cool to tackle this. They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries. Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there. There's e.g. Vulnix that scans for CVEs [1]. [1] https://github.com/flyingcircusio/vulnix
On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…
This is a flaw with the repository model for software distribution: it confers the authority of the OS developers to packages not scrutinized to the same degree. Users' metal models of trustworthiness don't track very well the actual scrutiny software is subjected to. This might be a problem with any distribution system.
It's a tough balancing act.
Earlier quoted context omitted.
That's about 95% of it. There are other things that give Linux a bit more of an edge in this space as well. For example, every time I use Windows, it feels like every app is asking to run as administrator. Admittedly, I haven't used Windows for about a year, but in Linux, it's pretty rare that I ever do admin/sudo outside of the command line, and I only ever use it when I know what I'm doing. Obviously this isn't som…
lets not forget the "curl blahblah.com | sudo bash" bit-o-insanity.
On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…
Depends on the attack vector. If the concern is inadvertent malware (i.e. an unaware developer incorporating a malicious library etc.) then I'd suspect the package repos would be a bit safer because they tend to act as a low pass filter (active source repos can change very frequently, downstream package repos much less so) and also act as one or more additional sets of eyes on the source code. Some developers can get…
Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last mile, often because its a lot of boring work. Mandatory Access Control should have been game changing in the security sphere, especially in the era of cgroups. Fine grained permissions controls in the kernel and filesystem would stomp out almost all potential m…
I’ve been hoping that we’ll get there for a couple decades but SELinux was quite the reminder that when faced with work a lot of people will just turn off a security measure and rant about it rather than contributing.