18 ms·

I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some st

I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions. Microsoft has started adding short life VMs. No idea if that's good. Both MS and Apple offer their App stores with more locked down experiences though I'm sad they conflate app security and app markets. Basically anytime I run any software, everytime I run "make" or "npm install" or "pip install" or download a game on Steam etc I'm having to trust 1000s of strangers they aren't downloading my keys, my photos, my docs, etc... I think you should be in control of your machine but IMO it's time to default to locked down instead of defaulting to open.

pulse7 7y ago
Maybe the future is in fully sandboxed/containerized apps, where each action outside of sandbox/container is confirmed by the user.
- y04nn 7y ago
  On freeBSD there is jails since year 2000.
  - blaser-waffle 7y ago
    Yeah I think about that each time my boss talks about how new and great docker and kubernetes are. It was old hat on FreeBSD 4.0 mate...
    - _jal 7y ago
      Jails, yes; k8, no. But I do have to say, the more Canonical and Redhat attempt to "innovate", the more I appreciate FreeBSD.
- UI_at_80x24 7y ago
  When Docker was first introduced this is exactly the niche I thought it was going to fill. After I elbows deep into it I saw that wasn't the case. I still think something like it could evolve to fill that role.
- vsareto 7y ago
  Alert fatigue -> user accepts everything
  - asdkhadsj 7y ago
    Is there a better solution though? I agree that's a super real thing, but having no security at all (as is the case now, basically) is infinitely worse. We would need to change some things, but I'd love to know if some random lib I'm using is trying to do things my application shouldn't. Or if something I installed, say Docker, is trying to access my photos or ssh keys.
  - stan_rogers 7y ago
    See Windows Vista for reference.
    - GordonS 7y ago
      This was my first thought too! It was also my first thought after I recently upgraded MacOS, and was bombarded with multiple permission dialogs whenever I did anything.
    - vokep 7y ago
      True, but this just makes the point more. Because after that was 7, with lessons learned. Gotta start somewhere
  - yarrel 7y ago
    That was my experience of SELinux.
- _jal 7y ago
  That is a super-broken future. I mean, that's working... sort of OK for cell-phone-style use, where the vast amount of use is single-service, casual human-computer interaction. It is horrible for any reasonable professional workflow. Even if you get permissions lined up correctly once, when you change your workflow, shit breaks. and more subtly, the way permissions accrete through reactive interactive dialogs, folks become less secure over time - past permission "paths" enable capabilities that the user no longer even remembers making. More formal ways of defining security policy of course work better (I deal with that sort of thing for a living), but expecting normal people to be able to understand how to, e.g., use `restorecon` or the moral equivalent is a nonstarter. Personally, I'm headed back to Linux when I need to replace the Macbook I'm typing on. I'm no longer the target MacOS user, and I'm not going to rely on a machine I don't control.
XorNot 7y ago
This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.
- ownagefool 7y ago
  There's a fair amount of other solutions to this too. Things today: - Protective monitoring. If it's stealing your key, it's presumably sending it somewhere, so somebody alerting should be going off asking clients are calling something external. - Peer review. Maybe its about time we question whether we should actually be running so many random modules without actually vendoring and reading the code. - Subscribing to security lists, so the people who actually do the above stop you from using dirty modules. - Yubikeys, etc. Things in the future: - New home directory model. I believe systemd crew are looking into this, so I imagine it'll be hated, even if it does help solve similar issues. - Newer distro models such as fedora silverblue where every process is isolated. I believe this currently mounts your home directory though, so maybe wouldn't work. - New FS layout. Putting .ssh keys in something like .secret/ssh would likely make it easier to not mount secrets into isolated processes and help MACs too.
  - vsareto 7y ago
    Monitoring isn't really a solution, it just lets you know you need to make new keys and gives you a point in time to figure out if they were used after being compromised
    - ownagefool 7y ago
      You're right monitoring doesn't stop your key from being stolen, but it might stop your key being used or for the vulnerability being used again.
    - tluyben2 7y ago
      In the way OP suggests, it is; it's kind of like Zonealarm (I have no clue if that still exists; I haven't used Windows for a long time); so it will block a process before sending it and asking the user for permission to send something to X.com. It will do that with every change of X.com. You can allow your process everything of course, but it was convenient enough to block most everything evil while letting through only what I wanted without giving my dev (or any other processes) permission to send to ..
e2le 7y ago
I suspect the solution is a combination of selinux (apparmor?) and curated code repositories. I don't think sandboxing alone is a solution as it doesn't alleviate concerns with zero days.
riyakhanna1983 7y ago
SandFS could be used for lightweight custom sandboxing $HOME dir. It uses eBPF to let you insert custom checks. Check https://lwn.net/Articles/803890/ https://lwn.net/Articles/803890/
whack 7y ago
When I first realized that any and all code that I execute, has read/write permissions to most of my filesystem, it blew my mind. The OS grants every process its own unique virtual-memory-space, specifically to prevent malicious/accidental interference with other processes. It seems like the file-system really should operate on a similar principle as well. Every application should run in a sandboxed environment by default, with exceptions being granted by the user for specific applications that actually do need access to the entire file system.
- umanwizard 7y ago
  This is already possible in Linux with mount namespaces, and used by (for example) systemd to block access to /home by services if so configured by the user.
  - GordonS 7y ago
    I wonder if there is a Linux distro out there that works like the OP wanted out-of-the-box, with userland processes sandboxes by default, and providing a slick interface to grant access to areas of the filesystem when wanted? There are so many distros with little differentiation - I'd think something like this would be quite unique (unless it already exists, and I don't know it!)
    - filipMar 7y ago
      Do you mean something like Fedora silverblue?
  - olejorgenb 7y ago
    https://github.com/netblue30/firejail https://github.com/netblue30/firejail
danieldk 7y ago
For this particular case: if you have GnuPG or SSH private keys, do not store them on-disk. Use a hardware token, such as a gnuk token, or a token with a secure element if you also want resistance against physical key exfiltration. A gnuk-based hardware token can be had in a nice format for under 30 Euro [1] or you could buy a STM32F103-based microcontroller for a few bucks and flash gnuk [2] if you like DIY. If you are a company, invest the 50 Euro in hardware tokens for your employees, one compromised SSH private key means that all the machines that use the public key are suspect. I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions. I fully agree. It seems that the UNIX model is not very compatible with the macOS permission system, but one could imagine defining multiple types of shell sessions, each with its own set of permissions. [1] https://www.nitrokey.com/ https://www.nitrokey.com/ [2] https://salsa.debian.org/gnuk-team/gnuk/gnuk https://salsa.debian.org/gnuk-team/gnuk/gnuk
- Xylakant 7y ago
  yubikeys can store GPG keys and emulate SSH keys via gpg-agent. More exciting: OpenSSL recently added full U2F/Fido support, but it might take a bit until that lands in all distros https://www.undeadly.org/cgi?action=article;sid=20191115064850 https://www.undeadly.org/cgi?action=article;sid=201911150648...
  - danieldk 7y ago
    yubikeys can store GPG keys and emulate SSH keys via gpg-agent. Indeed. Same for gnuk keys. I currently use a gnuk key (Nitrokey Start) with Ed25519 and have GPG set up as the SSH agent for SSH. Though I hope to switch to a YubiKey soon, so that I don't need a separate key for U2F/Fido2.
    - Xylakant 7y ago
de_watcher 7y ago
Maintainers Matter: http://kmkeen.com/maintainers-matter/ http://kmkeen.com/maintainers-matter/
asdkhadsj 7y ago
> Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions. Would Python permissions even be enough though? All it takes is one legitimate Python application wanting your Photos (lets say some Python photo manager app you wrote) and now all Python libraries get access. Unfortunately, I think Apple's direction may be correct. It feels hugely inconvenient, but an end goal of all processes being signed and explicitly allowed certain things seems useful. At the very least, Python should perhaps never get access to anything beyond the devving folder. Then any real use of Python applications would have to be properly baked out into processes where the OS can manage permissions for. This goes for all languages, Python was just an example here. This is all off the top of my head, so I could be way off base. But it seems logical to me in the moment.
- narrator 7y ago
  The no setuid shell scripts rule on Linux was an early attempt to deal with this. https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts https://unix.stackexchange.com/questions/364/allow-setuid-on...
- tomp 7y ago
  > Unfortunately, I think Apple's direction may be correct. It feels hugely inconvenient, but an end goal of all processes being signed and explicitly allowed certain things seems useful. Apple is operating a racket. There's e.g. no need for signing (and developers buying expensive certificates), you could also have a dedicated "permissions agent" checking executable hashes against an online service, and giving them as many permissions as desired... So users could (1) pick and choose their "permissions providers" (not necessarily Apple, could also be e.g. GNUpermissions or WikiPermissions or whatever), (2) users could modify permissions (e.g. provider defaults to Web Access but I want to deny it for this specific executable), and (3) all (even unsigned) programs could run, but with minimal permissions by default (i.e. sandboxed).
- notatoad 7y ago
  Wasn't this the promise of containers? "python" should have access to the whole system that it is run on, but instead of running random python scripts you download from the internet on your base system that has all your personal data in it, you run it in a container that only has the specific files that the script needs access to.
equalunique 7y ago
Use SELinux
nnx 7y ago
https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/ https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... is a step in the right direction.
htns 7y ago
Qubes OS already exists! It's been perfectly usable for more than a decade now. It can't be recommended enough: https://www.qubes-os.org/ https://www.qubes-os.org/ Sadly "modern security awareness" doesn't seem to really amount to anything, and existing solutions go unused. %90 of this "malware library" problem too would have been avoided if package repositories just required all packages to be signed with keys on hardware dongles. Ruby and python and some others at least have the excuse of inertia, but it's pretty cynical of everything else to not require signing already, when the added friction is nothing relative to the effort of writing software worth publishing.
- fwip 7y ago
  I don't think that's a good solution. A) it adds cost to what was previously free for many people B) it does nothing to deter bad actors C) many software packages would be abandoned because their dongle was lost or destroyed
- tkfu 7y ago
  > %90 of this "malware library" problem too would have been avoided if package repositories just required all packages to be signed with keys on hardware dongles. I'm with you about requiring signatures, and you can get around the FUD about packages getting abandoned because of developers losing keys by implementing something like TUF[1] (because of delegations in the targets role), but I don't really see how you can enforce dongle usage. That is, how can the repository administrators tell the difference between a signature from a key on a hardware dongle and a signature from a key on somebody's windows laptop? You'd need an IRL auditing process, which just isn't feasible for most open source packages. [1] https://theupdateframework.github.io/ https://theupdateframework.github.io/
  - htns 7y ago
    I don't have any particular definitive solution in mind. Attestation is possible (e.g. https://developers.yubico.com/PGP/Attestation.html https://developers.yubico.com/PGP/Attestation.html), but just telling people to do it right should go pretty far, especially if the packaging software doesn't cater to circumventing the policy.
omarhaneef 7y ago
Some "easy" tools: 1. Ban libraries that have names that might confused with others (so no I where L is etc). 2. Only use libraries that have been around for over 1 year (you're relying on the community to debug them). I think with these two alone you might get rid of most issues. The problem is that someone might buy an old, trusted name and then inject malicious code. I don't know of a technical way to enforce change of ownership that might be useful and not too much work. Alternatively a nefarious player might release useful code, bide their time to get a reputation, and then inject malicious code. Short Life VMs are a good idea but sometimes you want them all to talk to each other.
- ezzzzz 7y ago
  > Ban libraries that have names that might confused with others (so no I where L is etc). I agree that this is some obvious low-lying fruit here. Given that the onus is currently on devs here, an actionable solution today is to use a font which makes the differences between i, I, L, 1 easily distinguishable (obviously not fool-proof), or bake a check for malevolently named dependencies into your linter or plugin.
- jonathanstrange 7y ago
  The problems are forks, though. Anybody can create a copy and the problem is that e.g. on Github there are tons of library clones that aren't even marked as fork, because they have been cloned and then imported as a new library for whatever reason by the new maintainer. I've often had substantial troubles finding the original library or the most well-maintained fork. Large repos like Github should do an automated similarity search and prominently display potential older (as in creation date) versions of the same library even if they are not forked from the original repo directly.
neves 7y ago
When I see any software updating its dependencies or an app store I think the security battle is lost. It's very easy for any gov intelligence agency to seize an abandoned software and start to use it to distribute spyware.
dbrgn 7y ago
Flatpak offers sandboxing, but I think it's mostly meant for applications, not for development tools (where you often need to access your keys anyways).
simias 7y ago
The problem is convenience vs. security, and we all know that even knowledgeable users will often sacrifice the latter for the former. Technically on many OSs you already have dozens of ways to achieve what you're saying. You could spawn a VM, use a different user, use some container framework, use SELinux, etc... The problem is that usability is generally terrible. Or maybe not terrible but bad enough that many people will start mashing the "allow" button indiscriminately when they're in a hurry and want the thing to Just Work. There's only one thing I know for sure how to do with SELinux without having to lookup a guide or manual, it's how to disable it. Look at the modern Linux desktop for instance, you need admin privileges to configure a printer but your sensitive private files are just lying on your home directory with user privileges. That makes no sense. This is not really a technical problem, that was solved when we invented the MMU, it's an UI problem.
- eythian 7y ago
  > Look at the modern Linux desktop for instance, you need admin privileges to configure a printer Not for an amount of time that is firmly outside "modern."
  - codedokode 7y ago
    Yes because otherwise one user could configure a fake printer and see what others are printing. Although for one-user system this doesn't make much sense.
    - sitkack 7y ago
      Maybe there should be a trust chain for everything.
    - simias 7y ago
      Right, that's the problem IMO, the usual way processes are segregated on Linux harks back to the day of UNIX mainframes shared across dozens of users. It still makes some sense on servers where you want to isolate, say, the database from the web server from postfix from sshd but it's almost entirely inadequate for single-user desktop computers. On my desktop root doesn't really matter, if my user gets compromised it's already game over. I have a lot more to lose if by browser gets backdoored that if my /etc/shadow gets leaked.
Abishek_Muthian 7y ago
You can add android to the list, any app which is given storage access can access any of your files there. So, if we had downloaded sensitive.pdf from email and it lies in the downloads; theoretically any of the dozen apps which has storage access permission can siphon it off to their server. Android Q has 'scoped storage access' to prevent this and individual folder access permission; but is optional and will be enforced only in the next major android version which by android update standards will take another 5-6 years to get widely adopted.
danShumway 7y ago
For a long time, the security model of OSes has been, "only trusted code should run." That model doesn't work. Code affects too much of our life and is used in too many scenarios for a binary "trusted" boolean to be feasible for most people. Offices and houses have locks inside of them as well as outside. If I invite someone into my office, they don't immediately have the key to my server room. But (while I agree that software bloat is a problem) you'll still find plenty of people after these issues who argue that having too many packages is the real security issue, and really all this comes down to is vetting our repositories better, or forcing everything to be signed, or whatever. In reality, the long-term solution is that we have to start taking native sandboxing seriously -- embracing efforts like Wayland, Flatpak, SE Linux, JS Realms, and turning on secure sandboxing systems by default. The problem isn't NPM or PyPi, it's Node/Python sandboxing. The problem isn't allowing arbitrary browser extensions, it's per-domain extension sandboxing. The problem isn't third-party scripts, it's browser fingerprinting. It is impossible to scale a trustworthy repository to the size of NPM, or PyPi, or the Apple store, or AUR, or the Chrome web store. There is not, and is never going to be, a trustworthy repository of that scale. In the meantime, because most platforms don't have serious sandboxing controls turned on by default, you just have to reduce your dependencies and install less software. But that band-aide fix will get less and less useful over time, because more and more of your life will depend on software from more and more diverse sources, and it will be impossible for you to vet everything. Being conservative about dependencies and code you run is an extremely temporary fix that is not going to work in the future. But people treat it like it's the obvious solution and that we don't have any need to address the fact that most consumer-grade OSes, platforms, and runtimes are simply crap at security.
tarsinge 7y ago
> my keys, my photos, my docs You listed it, the problem is personal data. If an executable nuke my computer it’s a pain but if they don’t have access to my data it’s not that severe. For a long time we conflated the two, being hacked / getting a virus meant you got downtime, and you were screwed if you didn’t have backup, but it stopped here. But really what changed in recent years in threat level is how much personal informations are in computers, and classic security models were not thought with that in mind. There is no « personal data » flag, just a permission it belongs to a user. It worked fine for executables and working documents, but personal data are a different thing.
continuational 7y ago
Why is it that we accept that any piece of code can just randomly reach into the file system and connect to any server? Why isn't the file system an object you pass around instead?
- greggman2 7y ago
  I agree with this as well. I feel like the OS should require apps to specify which domains they'll connect to and they should be allowed to only to connect to those domains. Yes you should be able to specify all domains like if you're making Firefox but otherwise it should be looked on with huge suspicion to list more than a couple. As it is any app/install script/build and scan my local network, find out my SSIDs, tell what devices are connected to my lan, which ports are open, what software is on some of those ports, and of course exploit any known vulnerabilities. I have a guest WiFi partly for that reason so when guest come over their apps hopefully can't hack stuff on my non-guest network. Unfortunately every new game/app/dep I install on my phone/pc/mac/tv/appletv/ps4/switch can still do that and while I might trust the app devs I don't trust the library devs, especially the analytics libs compiled into every game.
- jerf 7y ago
  The phrase you're looking for to poke into a search engine is "capability-based security": https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security It's a long, kinda story, which I'm not intimately familiar with, but seems to boil down to, it's more effort than we're willing to spend on rebooting our entire computing infrastructure. (Lots of things that could improve computing have that problem. "Rebooting our entire computing infrastructure" is a boil-the-ocean problem now.)
  - gnufx 7y ago
    I'm not sure to what extent "rebooting our entire computing infrastructure" is necessary. Current OS efforts with capability security include SEL4, Genode, and Google's Fuschia, but Cambridge's Capsicum "hybrid" system adds capability primitives to the POSIX API. (Their CHERI capability hardware recently made the news with funding.)
staticassertion 7y ago
Just have package managers run as a separate user in a separate namespace? I don't get why we let packages do crazy shit on our system as a fully privileged user. Look to browsers, imo. 'Extensions', which are very analogous to packages, have to package a manifest, users must explicitly ack the permissions, and they have restricted access to the system.
- Kalium 7y ago
  Most packaging systems are designed with the expectation that they will be installing arbitrary things that can interact with one another in arbitrary ways that should not have to be defined in advance for a given package. The result has been a very hands-off approach. Package management systems for user-land libraries, like pip and so on, are extra guilty of being hands-off. And who wants their dev tools telling them what they can and can't do?
  - staticassertion 7y ago
    Yeah I think it's totally insane. If your package requires a system dependency, like a binary, it should simply fail to install and let you know that you should go get that dependency. It should not, instead, require root privileges to add that to your system. Or, we should be providing virtualization like containers so that it can do 'root-y things' safely.
    - Kalium 7y ago
      It sounds like you're describing snap packages. Is that accurate? That mostly works for whole applications. I'm not sure how to apply it to libraries for developers though. Especially ones that would get installed in userspace, like these python packages.
      - staticassertion 7y ago
        I'm not super familiar with snap, my weak understanding is that it makes for a very poor isolation boundary.
ozim 7y ago
You know you should not run as root and you should not install all kind of crap on your computer. Every time you walk on the street you have to trust 1000s of strangers they are not going to murder you or rob you. You also know you should not go into dark alleys alone at night. This is just how life works.
WorldMaker 7y ago
> Microsoft has started adding short life VMs. No idea if that's good. The lightweight sandbox VMs seem to be pretty useful so far. It's still so new that I've not seen it used outside of blog posts yet, but that's the nature of cutting edge features only "just" released. (It was released with 1903 in May, which was delayed several months and a lot of businesses still are hesitant to install it.) Windows 10 has had Controlled Folder Access (aka Ransomware Protection) available as an option for a while as well, which acts like Apple's system of forcing apps to need additional permissions to user directories. It's not quite as fine-grained as Apple's yet, and it is certainly not on by default. (I turned it on for interesting paranoia reasons on my gaming desktop, and it's been fascinating to watch what gets blocked. Though my paranoia led me to adding Steam folders to the Controlled Folders list, which has especially made it a permissions whack-a-mole because Game Developers are children and games access random folders all the time, use five EXEs where one probably should have been enough, use random EXEs in TEMP folders to call EXEs in Steam folders, games not installed by Steam sometimes try to access Steam folders, NVidia wants to touch everything, etc.) > Both MS and Apple offer their App stores with more locked down experiences though I'm sad they conflate app security and app markets. Windows 10 has had sideloading on by default for years now, and supports Win32 apps inside APPX/MSIX. Win32 apps by default aren't nearly as sandboxed sadly (because it is hard to guarantee Win32 apps work as expected when sandboxed), but some sandboxing is better than none. The biggest issue seems a lot less to do with "app market" (you don't have to publish to the Microsoft Store, and MSIX even supports auto-updating for sideloaded apps vaguely "ClickOnce-style") and a lot more to do with "please rebuild your installer to something more modern", which is a hurdle a lot of developers don't want to overcome. (Because installers are terrible and once one is built who wants to rebuild it. Because MSIX support for Windows 7 is still "Beta" with the April end-of-support for Windows 7 looming over everything, and some Enterprises clutching their Windows 7 purses as the new XP...) Who wants extra app security when it means a lot of development effort to repackage your app? (Even if it can be semi-automated from your existing installer.)
icefog 7y ago
OpenBSD has a really novel concept of using unveil and pledge to contain processes into restricted-service operating modes. And being OpenBSD, these security features are actually turned on by default for many binaries. See discussion in https://news.ycombinator.com/item?id=17277067 https://news.ycombinator.com/item?id=17277067
- saagarjha 7y ago
  macOS has this already.
  - icefog 7y ago
    Does it? On OpenBSD, Chrome cannot read my ~/.ssh directory, can the same guarantee be made on Mac?
    - saagarjha 7y ago
      Yes, you can write custom sandbox profiles and apply themselves to yourself using sandbox_init(3).
      - icefog 7y ago
        Good to know, but I don't need to write anything on OpenBSD. The protection is just enabled by default. That is more comforting to me as a user.
        saagarjha 7y ago
        Certain programs have default protections applied to them, such as most App Store apps.
gnl 7y ago
This is spot-on. In a perfect world every major OS would have proper, granular mandatory access control enabled by default and applications would come with a profile specifying precisely which resources they require – at least regarding the more critical stuff like keys and cookies – with attempts to access anything else triggering an optional notification. Hopefully macOS will become more granular that way and Apple will continue pushing and improving what they began with Catalina. Meanwhile, in a less than perfect world there's XFENCE [0], previously known as LittleFlocker. It's basically LittleSnitch for files. It was originally developed by Jonathan Zdziarski and later sold to F-Secure. The challenge is to set it up in such a way that the level of interaction is kept at a minimum while still providing some level of protection. I might write a detailed blog post / howto about it, but meanwhile here's the TL;DR if someone wants to try this blacklist/greylist approach: 1. Set an 'Allow any app – rwc' rule for /Users to override the default 'Watch – rw' rule there, which would otherwise result in a ton of popups. This does not override the more specific watch rules for some critical resources like loginitems, etc. 2. Add watch rules for additional critical resources, like ~/.gnupg, ~/.ssh, ~/bin, possible password manager directories, Firefox/Chrome directories to prevent cookie extraction, etc. 3. Temporarily add a watch rwc rule for ~/, thus overriding the Allow rule for /Users. 4. Run any network connected software with a potentially large attack surface like browsers, torrent clients, vpn clients, etc. and give them the required permissions to your home directory using the popups. Make sure to put them through their paces in terms of file system access to cover all possible use cases. 5. When they are usable without any more popups, remove the temporary watch rule and add 'Deny rwc to /Users' rules for each one, thus overriding the general /Allow rule we created above. An application-specific watch rule would be nice here instead, but sadly that doesn't seem to be possible – watch rules apply to all applications. Execute steps 3–5 for any other untrusted software you might want to install/run. When combined with LittleSnitch to catch possible attempts at data extraction, this reduces the risk of rogue applications extracting/damaging critical data and limits the potential damage of possible RCE vulnerabilities in network connected software. And it does this with a minimum of interaction – after the initial setup phase. I've been running LittleFlocker/XFENCE for a couple of years now and the setup described above for maybe a year and it works like a charm, currently on Mojave, previously High Sierra, all the way back to Capitan, if memory serves. A whitelist approach would of course be more secure, but that's way too stressful and distracting for me. [0] https://community.f-secure.com/t5/Home-Security/XFENCE-beta-1-8-90-released/td-p/112625 https://community.f-secure.com/t5/Home-Security/XFENCE-beta-...
ris 7y ago
The first step is to reject the fashionable "wild-west" style of package repositories and realize that maintained repositories came about for a reason. Then you can worry about rearchitecting your OS for sandboxes up the wazoo.
bdamm 7y ago
Yep, and Apple, Google and Microsoft aren't helping. Particularly bad these days is the idea of granting apps permissions; for example, if I want to deploy a new Google Drive application for some whiz-bang thing, I almost certainly need to "Grant read and write for all documents." Well, I don't want to do that, so I don't use any Google Drive add-ons ever. Is there a way to restrict privileges by folder? Nope! Same is true for Microsoft Office 365. Apple is trying, but still a long way to go.
- canada_dry 7y ago
  > Is there a way to restrict privileges by folder? Nope! Playing devil's advocate... I'm sure most folks here appreciate that providing granular level of permissions/restrictions can often lead to a less secure environment! Users (of pretty much every skill level) quickly become overwhelmed and give up. I recall advocating that a large client group manage their own permissions in Sharepoint. It was a painful and futile exercise! Though really not much different than IT admins trying to managing security of a large organization using active directory.
  - bdamm 7y ago
    Yes, it's important to have great tools for helping users with this. Just like how Google Drive goes to great lengths to show which folders are shared and give the user good access to those policies. All I want is for an application to be subject to policies just like other users are. Is that so hard? And honestly, to provide all this tooling for being careful who you share files with, while providing none of that to being careful about which applications I share data with, is a little bit disingenuous about the relationship between people and applications. People write and operate applications, so when I am sharing my data with applications, I am sharing it with people too. I just don't get to find out who or have any specific control over that.
- tzs 7y ago
  You could probably do something with access control lists and setuid/setgid. Take a set of programs that all should have the same set of accessible folders and the same set of inaccessible folders, and make them setuid to the same UID, and then add the appropriate entries for that UID to the access control lists for all those folders. The usual interfaces for manipulating ACLs are not very friendly so you'd want to have some kind of tool to set this thing up. Managing the ACLs, and managing the program grouping UIDs, and making it so things don't get regularly broken by package managers that don't know about this system is probably going to be challenging. What I'd like to see is someone make an access control system for Unix based off of the ideas from the old DEC PDP-10 operating system TOPS-10 file daemon system. TOPS-10 originally just had owner/group based access. Later, they added the file daemon access control system. The way that worked is simple: 1. If an access was allowed by the owner/group system, it went through normally. 2. If an access was NOT allowed by the owner/group system, and the new "use file daemon" flag had not been set by the caller, the accesses was denied. 3. If, on the other hand, the "use file daemon" flag was set, the OS sent a message to the file daemon describing the desired access, and asking the file daemon if it should be allowed or not. Whether the OS allowed the access or not was determined by the file daemon. In what follows I'm probably getting some details wrong, but the general idea is right. The way file daemon made its decision was by consulting a rules file containing access rules. The rules file was named ACCESS.USR. I don't remember if file daemon looked for that in the same directory as the file it was being asked about, in the home directory of the owner of the file, or what. The key idea is that the access rules for a file were in ACCESS.USR, NOT in metadata of the file itself. ACCESS.USR allowed for wildcards, so one rule in there could specify the access rights for a whole class of files--including files that did not yet exist. My recollection is that the rule matching could be based on the name of the file someone is trying to access (full or partial, with wildcards), the user and group that is trying for access (I believe wildcards were allowed here, too), and what program was being used. So let's say you wrote a game, and it wanted to keep a high score file. You could make an entry in ACCESS.USR that said anyone was allowed write access to SCORES.TXT if they were running EMPIRE.EXE. (Picking EMPIRE for my example in the hopes of summoning Walter Bright, since he probably remembers more details than I do about file daemon). Then just make sure to set the permissions on SCORES.TXT so that access by anyone other than yourself will fail, and make sure that EMPIRE.EXE sets the "use file daemon" flag when it tries to write the score file. This fits in well with the way users think about things. For example, let's say I've got public and private key files. My public key files have .PUB extensions and my private key files have .KEY extensions. It is easy to put a rule in ACCESS.USR that denies all others access to my .KEY files. If I do something that creates a new .KEY file, I don't have to make sure whatever tool created it set the ACLs...I just have to make sure I use a .KEY extension. It's a lot easier to develop and maintain a naming convention that reflects my security requirements and stick to that than it is to manage per file ACLs that reflect my requirements.
ufmace 7y ago
This sounds kind of like what Microsoft did with UAC in Windows Vista. As I recall, it was a terrible experience and everybody hated it. Seems like the trouble is that the huge installed base of applications have no accommodations for anything like that, which makes it awful to try to impose stricter permission requirements now. Even imagining how is kind of tough. How do you let some Python scripts, but not others, access certain directories, like the ones with your SSH keys? It would have to be built into Python, which may mean major changes to tons of packages. Ditto Ruby, NodeJS, Perl, PHP, and every other interpreted language out there. And how do you develop compiled applications in such an env? Suppose every new build would have to be signed with the expected permissions. But how would you let one internal package access a dir, but not some other one? More internal permission systems I guess?
IshKebab 7y ago
We need library level isolation, not just app level isolation (which desktop OSes don't even bother with). Fortunately there's some amazing work on supporting library isolation in WASM. There was a really good blog post about it recently.
srcmap 7y ago
In the old day, I used ZoneAlarm to alert me / block any app that was trying connect to any networks by default. Does anyone know similar solution for today's win10, Linux, Android environment? Win10's firewall is ok for blocking when configure manually. But it lacks the "alert" functionalities on any new app/connections requests.
StreamBright 7y ago
I absolutely agree with you. An OS should be many read only folders like /kernel /etc /bin that can be changed in an update process (that requires reboot) and folder where you give access to specific applications like /bin/ssh ro -> .ssh/id_rsa. Python process should not have read access to this folder by default at all. There are other solutions that you move all the credential access to a service that is accessed on a port by applications using tokens with different privileges. The current implementation of operating systems are pretty horrid, retrofit security all over. I think we are ready for a new OS era.
grumple 7y ago
Running everything in containers seems to make sense.
jbergens 7y ago
Windows have had locks for specific things for many years. They also created a new model with sandboxed runtimes för Windows Store Apps but those are not very popular. Yarn, a ja package manager, tried to forbid any code execution during installs. That may be a good idea. At least show a warning or require an extra flag before executing anything.

pulse7 7y ago

Maybe the future is in fully sandboxed/containerized apps, where each action outside of sandbox/container is confirmed by the user.

y04nn 7y ago
On freeBSD there is jails since year 2000.
- blaser-waffle 7y ago
  Yeah I think about that each time my boss talks about how new and great docker and kubernetes are. It was old hat on FreeBSD 4.0 mate...
  - _jal 7y ago
    Jails, yes; k8, no. But I do have to say, the more Canonical and Redhat attempt to "innovate", the more I appreciate FreeBSD.
UI_at_80x24 7y ago
When Docker was first introduced this is exactly the niche I thought it was going to fill. After I elbows deep into it I saw that wasn't the case. I still think something like it could evolve to fill that role.
vsareto 7y ago
Alert fatigue -> user accepts everything
- asdkhadsj 7y ago
  Is there a better solution though? I agree that's a super real thing, but having no security at all (as is the case now, basically) is infinitely worse. We would need to change some things, but I'd love to know if some random lib I'm using is trying to do things my application shouldn't. Or if something I installed, say Docker, is trying to access my photos or ssh keys.
- stan_rogers 7y ago
  See Windows Vista for reference.
  - GordonS 7y ago
    This was my first thought too! It was also my first thought after I recently upgraded MacOS, and was bombarded with multiple permission dialogs whenever I did anything.
  - vokep 7y ago
    True, but this just makes the point more. Because after that was 7, with lessons learned. Gotta start somewhere
- yarrel 7y ago
  That was my experience of SELinux.
_jal 7y ago
That is a super-broken future. I mean, that's working... sort of OK for cell-phone-style use, where the vast amount of use is single-service, casual human-computer interaction. It is horrible for any reasonable professional workflow. Even if you get permissions lined up correctly once, when you change your workflow, shit breaks. and more subtly, the way permissions accrete through reactive interactive dialogs, folks become less secure over time - past permission "paths" enable capabilities that the user no longer even remembers making. More formal ways of defining security policy of course work better (I deal with that sort of thing for a living), but expecting normal people to be able to understand how to, e.g., use `restorecon` or the moral equivalent is a nonstarter. Personally, I'm headed back to Linux when I need to replace the Macbook I'm typing on. I'm no longer the target MacOS user, and I'm not going to rely on a machine I don't control.

XorNot 7y ago

This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.

ownagefool 7y ago
There's a fair amount of other solutions to this too. Things today: - Protective monitoring. If it's stealing your key, it's presumably sending it somewhere, so somebody alerting should be going off asking clients are calling something external. - Peer review. Maybe its about time we question whether we should actually be running so many random modules without actually vendoring and reading the code. - Subscribing to security lists, so the people who actually do the above stop you from using dirty modules. - Yubikeys, etc. Things in the future: - New home directory model. I believe systemd crew are looking into this, so I imagine it'll be hated, even if it does help solve similar issues. - Newer distro models such as fedora silverblue where every process is isolated. I believe this currently mounts your home directory though, so maybe wouldn't work. - New FS layout. Putting .ssh keys in something like .secret/ssh would likely make it easier to not mount secrets into isolated processes and help MACs too.
- vsareto 7y ago
  Monitoring isn't really a solution, it just lets you know you need to make new keys and gives you a point in time to figure out if they were used after being compromised
  - ownagefool 7y ago
    You're right monitoring doesn't stop your key from being stolen, but it might stop your key being used or for the vulnerability being used again.
  - tluyben2 7y ago
    In the way OP suggests, it is; it's kind of like Zonealarm (I have no clue if that still exists; I haven't used Windows for a long time); so it will block a process before sending it and asking the user for permission to send something to X.com. It will do that with every change of X.com. You can allow your process everything of course, but it was convenient enough to block most everything evil while letting through only what I wanted without giving my dev (or any other processes) permission to send to ..

e2le 7y ago

I suspect the solution is a combination of selinux (apparmor?) and curated code repositories. I don't think sandboxing alone is a solution as it doesn't alleviate concerns with zero days.

riyakhanna1983 7y ago

SandFS could be used for lightweight custom sandboxing $HOME dir. It uses eBPF to let you insert custom checks. Check https://lwn.net/Articles/803890/ https://lwn.net/Articles/803890/

whack 7y ago

When I first realized that any and all code that I execute, has read/write permissions to most of my filesystem, it blew my mind. The OS grants every process its own unique virtual-memory-space, specifically to prevent malicious/accidental interference with other processes. It seems like the file-system really should operate on a similar principle as well. Every application should run in a sandboxed environment by default, with exceptions being granted by the user for specific applications that actually do need access to the entire file system.

umanwizard 7y ago
This is already possible in Linux with mount namespaces, and used by (for example) systemd to block access to /home by services if so configured by the user.
- GordonS 7y ago
  I wonder if there is a Linux distro out there that works like the OP wanted out-of-the-box, with userland processes sandboxes by default, and providing a slick interface to grant access to areas of the filesystem when wanted? There are so many distros with little differentiation - I'd think something like this would be quite unique (unless it already exists, and I don't know it!)
  - filipMar 7y ago
    Do you mean something like Fedora silverblue?
- olejorgenb 7y ago
  https://github.com/netblue30/firejail https://github.com/netblue30/firejail

danieldk 7y ago

For this particular case: if you have GnuPG or SSH private keys, do not store them on-disk. Use a hardware token, such as a gnuk token, or a token with a secure element if you also want resistance against physical key exfiltration. A gnuk-based hardware token can be had in a nice format for under 30 Euro [1] or you could buy a STM32F103-based microcontroller for a few bucks and flash gnuk [2] if you like DIY. If you are a company, invest the 50 Euro in hardware tokens for your employees, one compromised SSH private key means that all the machines that use the public key are suspect. I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions. I fully agree. It seems that the UNIX model is not very compatible with the macOS permission system, but one could imagine defining multiple types of shell sessions, each with its own set of permissions. [1] https://www.nitrokey.com/ https://www.nitrokey.com/ [2] https://salsa.debian.org/gnuk-team/gnuk/gnuk https://salsa.debian.org/gnuk-team/gnuk/gnuk

Xylakant 7y ago
yubikeys can store GPG keys and emulate SSH keys via gpg-agent. More exciting: OpenSSL recently added full U2F/Fido support, but it might take a bit until that lands in all distros https://www.undeadly.org/cgi?action=article;sid=20191115064850 https://www.undeadly.org/cgi?action=article;sid=201911150648...
- danieldk 7y ago
  yubikeys can store GPG keys and emulate SSH keys via gpg-agent. Indeed. Same for gnuk keys. I currently use a gnuk key (Nitrokey Start) with Ed25519 and have GPG set up as the SSH agent for SSH. Though I hope to switch to a YubiKey soon, so that I don't need a separate key for U2F/Fido2.
  - Xylakant 7y ago

de_watcher 7y ago

Maintainers Matter: http://kmkeen.com/maintainers-matter/ http://kmkeen.com/maintainers-matter/

asdkhadsj 7y ago

> Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions. Would Python permissions even be enough though? All it takes is one legitimate Python application wanting your Photos (lets say some Python photo manager app you wrote) and now all Python libraries get access. Unfortunately, I think Apple's direction may be correct. It feels hugely inconvenient, but an end goal of all processes being signed and explicitly allowed certain things seems useful. At the very least, Python should perhaps never get access to anything beyond the devving folder. Then any real use of Python applications would have to be properly baked out into processes where the OS can manage permissions for. This goes for all languages, Python was just an example here. This is all off the top of my head, so I could be way off base. But it seems logical to me in the moment.

narrator 7y ago
The no setuid shell scripts rule on Linux was an early attempt to deal with this. https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts https://unix.stackexchange.com/questions/364/allow-setuid-on...
tomp 7y ago
> Unfortunately, I think Apple's direction may be correct. It feels hugely inconvenient, but an end goal of all processes being signed and explicitly allowed certain things seems useful. Apple is operating a racket. There's e.g. no need for signing (and developers buying expensive certificates), you could also have a dedicated "permissions agent" checking executable hashes against an online service, and giving them as many permissions as desired... So users could (1) pick and choose their "permissions providers" (not necessarily Apple, could also be e.g. GNUpermissions or WikiPermissions or whatever), (2) users could modify permissions (e.g. provider defaults to Web Access but I want to deny it for this specific executable), and (3) all (even unsigned) programs could run, but with minimal permissions by default (i.e. sandboxed).
notatoad 7y ago
Wasn't this the promise of containers? "python" should have access to the whole system that it is run on, but instead of running random python scripts you download from the internet on your base system that has all your personal data in it, you run it in a container that only has the specific files that the script needs access to.

equalunique 7y ago

Use SELinux

nnx 7y ago

https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/ https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... is a step in the right direction.

htns 7y ago

Qubes OS already exists! It's been perfectly usable for more than a decade now. It can't be recommended enough: https://www.qubes-os.org/ https://www.qubes-os.org/ Sadly "modern security awareness" doesn't seem to really amount to anything, and existing solutions go unused. %90 of this "malware library" problem too would have been avoided if package repositories just required all packages to be signed with keys on hardware dongles. Ruby and python and some others at least have the excuse of inertia, but it's pretty cynical of everything else to not require signing already, when the added friction is nothing relative to the effort of writing software worth publishing.

fwip 7y ago
I don't think that's a good solution. A) it adds cost to what was previously free for many people B) it does nothing to deter bad actors C) many software packages would be abandoned because their dongle was lost or destroyed
tkfu 7y ago
> %90 of this "malware library" problem too would have been avoided if package repositories just required all packages to be signed with keys on hardware dongles. I'm with you about requiring signatures, and you can get around the FUD about packages getting abandoned because of developers losing keys by implementing something like TUF[1] (because of delegations in the targets role), but I don't really see how you can enforce dongle usage. That is, how can the repository administrators tell the difference between a signature from a key on a hardware dongle and a signature from a key on somebody's windows laptop? You'd need an IRL auditing process, which just isn't feasible for most open source packages. [1] https://theupdateframework.github.io/ https://theupdateframework.github.io/
- htns 7y ago
  I don't have any particular definitive solution in mind. Attestation is possible (e.g. https://developers.yubico.com/PGP/Attestation.html https://developers.yubico.com/PGP/Attestation.html), but just telling people to do it right should go pretty far, especially if the packaging software doesn't cater to circumventing the policy.

omarhaneef 7y ago

Some "easy" tools: 1. Ban libraries that have names that might confused with others (so no I where L is etc). 2. Only use libraries that have been around for over 1 year (you're relying on the community to debug them). I think with these two alone you might get rid of most issues. The problem is that someone might buy an old, trusted name and then inject malicious code. I don't know of a technical way to enforce change of ownership that might be useful and not too much work. Alternatively a nefarious player might release useful code, bide their time to get a reputation, and then inject malicious code. Short Life VMs are a good idea but sometimes you want them all to talk to each other.

ezzzzz 7y ago
> Ban libraries that have names that might confused with others (so no I where L is etc). I agree that this is some obvious low-lying fruit here. Given that the onus is currently on devs here, an actionable solution today is to use a font which makes the differences between i, I, L, 1 easily distinguishable (obviously not fool-proof), or bake a check for malevolently named dependencies into your linter or plugin.
jonathanstrange 7y ago
The problems are forks, though. Anybody can create a copy and the problem is that e.g. on Github there are tons of library clones that aren't even marked as fork, because they have been cloned and then imported as a new library for whatever reason by the new maintainer. I've often had substantial troubles finding the original library or the most well-maintained fork. Large repos like Github should do an automated similarity search and prominently display potential older (as in creation date) versions of the same library even if they are not forked from the original repo directly.

neves 7y ago

When I see any software updating its dependencies or an app store I think the security battle is lost. It's very easy for any gov intelligence agency to seize an abandoned software and start to use it to distribute spyware.

dbrgn 7y ago

Flatpak offers sandboxing, but I think it's mostly meant for applications, not for development tools (where you often need to access your keys anyways).

simias 7y ago

The problem is convenience vs. security, and we all know that even knowledgeable users will often sacrifice the latter for the former. Technically on many OSs you already have dozens of ways to achieve what you're saying. You could spawn a VM, use a different user, use some container framework, use SELinux, etc... The problem is that usability is generally terrible. Or maybe not terrible but bad enough that many people will start mashing the "allow" button indiscriminately when they're in a hurry and want the thing to Just Work. There's only one thing I know for sure how to do with SELinux without having to lookup a guide or manual, it's how to disable it. Look at the modern Linux desktop for instance, you need admin privileges to configure a printer but your sensitive private files are just lying on your home directory with user privileges. That makes no sense. This is not really a technical problem, that was solved when we invented the MMU, it's an UI problem.

eythian 7y ago
> Look at the modern Linux desktop for instance, you need admin privileges to configure a printer Not for an amount of time that is firmly outside "modern."
- codedokode 7y ago
  Yes because otherwise one user could configure a fake printer and see what others are printing. Although for one-user system this doesn't make much sense.
  - sitkack 7y ago
    Maybe there should be a trust chain for everything.
  - simias 7y ago
    Right, that's the problem IMO, the usual way processes are segregated on Linux harks back to the day of UNIX mainframes shared across dozens of users. It still makes some sense on servers where you want to isolate, say, the database from the web server from postfix from sshd but it's almost entirely inadequate for single-user desktop computers. On my desktop root doesn't really matter, if my user gets compromised it's already game over. I have a lot more to lose if by browser gets backdoored that if my /etc/shadow gets leaked.

Abishek_Muthian 7y ago

You can add android to the list, any app which is given storage access can access any of your files there. So, if we had downloaded sensitive.pdf from email and it lies in the downloads; theoretically any of the dozen apps which has storage access permission can siphon it off to their server. Android Q has 'scoped storage access' to prevent this and individual folder access permission; but is optional and will be enforced only in the next major android version which by android update standards will take another 5-6 years to get widely adopted.

danShumway 7y ago

For a long time, the security model of OSes has been, "only trusted code should run." That model doesn't work. Code affects too much of our life and is used in too many scenarios for a binary "trusted" boolean to be feasible for most people. Offices and houses have locks inside of them as well as outside. If I invite someone into my office, they don't immediately have the key to my server room. But (while I agree that software bloat is a problem) you'll still find plenty of people after these issues who argue that having too many packages is the real security issue, and really all this comes down to is vetting our repositories better, or forcing everything to be signed, or whatever. In reality, the long-term solution is that we have to start taking native sandboxing seriously -- embracing efforts like Wayland, Flatpak, SE Linux, JS Realms, and turning on secure sandboxing systems by default. The problem isn't NPM or PyPi, it's Node/Python sandboxing. The problem isn't allowing arbitrary browser extensions, it's per-domain extension sandboxing. The problem isn't third-party scripts, it's browser fingerprinting. It is impossible to scale a trustworthy repository to the size of NPM, or PyPi, or the Apple store, or AUR, or the Chrome web store. There is not, and is never going to be, a trustworthy repository of that scale. In the meantime, because most platforms don't have serious sandboxing controls turned on by default, you just have to reduce your dependencies and install less software. But that band-aide fix will get less and less useful over time, because more and more of your life will depend on software from more and more diverse sources, and it will be impossible for you to vet everything. Being conservative about dependencies and code you run is an extremely temporary fix that is not going to work in the future. But people treat it like it's the obvious solution and that we don't have any need to address the fact that most consumer-grade OSes, platforms, and runtimes are simply crap at security.

tarsinge 7y ago

> my keys, my photos, my docs You listed it, the problem is personal data. If an executable nuke my computer it’s a pain but if they don’t have access to my data it’s not that severe. For a long time we conflated the two, being hacked / getting a virus meant you got downtime, and you were screwed if you didn’t have backup, but it stopped here. But really what changed in recent years in threat level is how much personal informations are in computers, and classic security models were not thought with that in mind. There is no « personal data » flag, just a permission it belongs to a user. It worked fine for executables and working documents, but personal data are a different thing.

continuational 7y ago

Why is it that we accept that any piece of code can just randomly reach into the file system and connect to any server? Why isn't the file system an object you pass around instead?

greggman2 7y ago
I agree with this as well. I feel like the OS should require apps to specify which domains they'll connect to and they should be allowed to only to connect to those domains. Yes you should be able to specify all domains like if you're making Firefox but otherwise it should be looked on with huge suspicion to list more than a couple. As it is any app/install script/build and scan my local network, find out my SSIDs, tell what devices are connected to my lan, which ports are open, what software is on some of those ports, and of course exploit any known vulnerabilities. I have a guest WiFi partly for that reason so when guest come over their apps hopefully can't hack stuff on my non-guest network. Unfortunately every new game/app/dep I install on my phone/pc/mac/tv/appletv/ps4/switch can still do that and while I might trust the app devs I don't trust the library devs, especially the analytics libs compiled into every game.
jerf 7y ago
The phrase you're looking for to poke into a search engine is "capability-based security": https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security It's a long, kinda story, which I'm not intimately familiar with, but seems to boil down to, it's more effort than we're willing to spend on rebooting our entire computing infrastructure. (Lots of things that could improve computing have that problem. "Rebooting our entire computing infrastructure" is a boil-the-ocean problem now.)
- gnufx 7y ago
  I'm not sure to what extent "rebooting our entire computing infrastructure" is necessary. Current OS efforts with capability security include SEL4, Genode, and Google's Fuschia, but Cambridge's Capsicum "hybrid" system adds capability primitives to the POSIX API. (Their CHERI capability hardware recently made the news with funding.)

staticassertion 7y ago

Just have package managers run as a separate user in a separate namespace? I don't get why we let packages do crazy shit on our system as a fully privileged user. Look to browsers, imo. 'Extensions', which are very analogous to packages, have to package a manifest, users must explicitly ack the permissions, and they have restricted access to the system.

Kalium 7y ago
Most packaging systems are designed with the expectation that they will be installing arbitrary things that can interact with one another in arbitrary ways that should not have to be defined in advance for a given package. The result has been a very hands-off approach. Package management systems for user-land libraries, like pip and so on, are extra guilty of being hands-off. And who wants their dev tools telling them what they can and can't do?
- staticassertion 7y ago
  Yeah I think it's totally insane. If your package requires a system dependency, like a binary, it should simply fail to install and let you know that you should go get that dependency. It should not, instead, require root privileges to add that to your system. Or, we should be providing virtualization like containers so that it can do 'root-y things' safely.
  - Kalium 7y ago
    It sounds like you're describing snap packages. Is that accurate? That mostly works for whole applications. I'm not sure how to apply it to libraries for developers though. Especially ones that would get installed in userspace, like these python packages.
    - staticassertion 7y ago
      I'm not super familiar with snap, my weak understanding is that it makes for a very poor isolation boundary.

ozim 7y ago

You know you should not run as root and you should not install all kind of crap on your computer. Every time you walk on the street you have to trust 1000s of strangers they are not going to murder you or rob you. You also know you should not go into dark alleys alone at night. This is just how life works.

WorldMaker 7y ago

> Microsoft has started adding short life VMs. No idea if that's good. The lightweight sandbox VMs seem to be pretty useful so far. It's still so new that I've not seen it used outside of blog posts yet, but that's the nature of cutting edge features only "just" released. (It was released with 1903 in May, which was delayed several months and a lot of businesses still are hesitant to install it.) Windows 10 has had Controlled Folder Access (aka Ransomware Protection) available as an option for a while as well, which acts like Apple's system of forcing apps to need additional permissions to user directories. It's not quite as fine-grained as Apple's yet, and it is certainly not on by default. (I turned it on for interesting paranoia reasons on my gaming desktop, and it's been fascinating to watch what gets blocked. Though my paranoia led me to adding Steam folders to the Controlled Folders list, which has especially made it a permissions whack-a-mole because Game Developers are children and games access random folders all the time, use five EXEs where one probably should have been enough, use random EXEs in TEMP folders to call EXEs in Steam folders, games not installed by Steam sometimes try to access Steam folders, NVidia wants to touch everything, etc.) > Both MS and Apple offer their App stores with more locked down experiences though I'm sad they conflate app security and app markets. Windows 10 has had sideloading on by default for years now, and supports Win32 apps inside APPX/MSIX. Win32 apps by default aren't nearly as sandboxed sadly (because it is hard to guarantee Win32 apps work as expected when sandboxed), but some sandboxing is better than none. The biggest issue seems a lot less to do with "app market" (you don't have to publish to the Microsoft Store, and MSIX even supports auto-updating for sideloaded apps vaguely "ClickOnce-style") and a lot more to do with "please rebuild your installer to something more modern", which is a hurdle a lot of developers don't want to overcome. (Because installers are terrible and once one is built who wants to rebuild it. Because MSIX support for Windows 7 is still "Beta" with the April end-of-support for Windows 7 looming over everything, and some Enterprises clutching their Windows 7 purses as the new XP...) Who wants extra app security when it means a lot of development effort to repackage your app? (Even if it can be semi-automated from your existing installer.)

icefog 7y ago

OpenBSD has a really novel concept of using unveil and pledge to contain processes into restricted-service operating modes. And being OpenBSD, these security features are actually turned on by default for many binaries. See discussion in https://news.ycombinator.com/item?id=17277067 https://news.ycombinator.com/item?id=17277067

saagarjha 7y ago
macOS has this already.
- icefog 7y ago
  Does it? On OpenBSD, Chrome cannot read my ~/.ssh directory, can the same guarantee be made on Mac?
  - saagarjha 7y ago
    Yes, you can write custom sandbox profiles and apply themselves to yourself using sandbox_init(3).
    - icefog 7y ago
      Good to know, but I don't need to write anything on OpenBSD. The protection is just enabled by default. That is more comforting to me as a user.
      - saagarjha 7y ago
        Certain programs have default protections applied to them, such as most App Store apps.

gnl 7y ago

This is spot-on. In a perfect world every major OS would have proper, granular mandatory access control enabled by default and applications would come with a profile specifying precisely which resources they require – at least regarding the more critical stuff like keys and cookies – with attempts to access anything else triggering an optional notification. Hopefully macOS will become more granular that way and Apple will continue pushing and improving what they began with Catalina. Meanwhile, in a less than perfect world there's XFENCE [0], previously known as LittleFlocker. It's basically LittleSnitch for files. It was originally developed by Jonathan Zdziarski and later sold to F-Secure. The challenge is to set it up in such a way that the level of interaction is kept at a minimum while still providing some level of protection. I might write a detailed blog post / howto about it, but meanwhile here's the TL;DR if someone wants to try this blacklist/greylist approach: 1. Set an 'Allow any app – rwc' rule for /Users to override the default 'Watch – rw' rule there, which would otherwise result in a ton of popups. This does not override the more specific watch rules for some critical resources like loginitems, etc. 2. Add watch rules for additional critical resources, like ~/.gnupg, ~/.ssh, ~/bin, possible password manager directories, Firefox/Chrome directories to prevent cookie extraction, etc. 3. Temporarily add a watch rwc rule for ~/, thus overriding the Allow rule for /Users. 4. Run any network connected software with a potentially large attack surface like browsers, torrent clients, vpn clients, etc. and give them the required permissions to your home directory using the popups. Make sure to put them through their paces in terms of file system access to cover all possible use cases. 5. When they are usable without any more popups, remove the temporary watch rule and add 'Deny rwc to /Users' rules for each one, thus overriding the general /Allow rule we created above. An application-specific watch rule would be nice here instead, but sadly that doesn't seem to be possible – watch rules apply to all applications. Execute steps 3–5 for any other untrusted software you might want to install/run. When combined with LittleSnitch to catch possible attempts at data extraction, this reduces the risk of rogue applications extracting/damaging critical data and limits the potential damage of possible RCE vulnerabilities in network connected software. And it does this with a minimum of interaction – after the initial setup phase. I've been running LittleFlocker/XFENCE for a couple of years now and the setup described above for maybe a year and it works like a charm, currently on Mojave, previously High Sierra, all the way back to Capitan, if memory serves. A whitelist approach would of course be more secure, but that's way too stressful and distracting for me. [0] https://community.f-secure.com/t5/Home-Security/XFENCE-beta-1-8-90-released/td-p/112625 https://community.f-secure.com/t5/Home-Security/XFENCE-beta-...

ris 7y ago

The first step is to reject the fashionable "wild-west" style of package repositories and realize that maintained repositories came about for a reason. Then you can worry about rearchitecting your OS for sandboxes up the wazoo.

bdamm 7y ago

Yep, and Apple, Google and Microsoft aren't helping. Particularly bad these days is the idea of granting apps permissions; for example, if I want to deploy a new Google Drive application for some whiz-bang thing, I almost certainly need to "Grant read and write for all documents." Well, I don't want to do that, so I don't use any Google Drive add-ons ever. Is there a way to restrict privileges by folder? Nope! Same is true for Microsoft Office 365. Apple is trying, but still a long way to go.

canada_dry 7y ago
> Is there a way to restrict privileges by folder? Nope! Playing devil's advocate... I'm sure most folks here appreciate that providing granular level of permissions/restrictions can often lead to a less secure environment! Users (of pretty much every skill level) quickly become overwhelmed and give up. I recall advocating that a large client group manage their own permissions in Sharepoint. It was a painful and futile exercise! Though really not much different than IT admins trying to managing security of a large organization using active directory.
- bdamm 7y ago
  Yes, it's important to have great tools for helping users with this. Just like how Google Drive goes to great lengths to show which folders are shared and give the user good access to those policies. All I want is for an application to be subject to policies just like other users are. Is that so hard? And honestly, to provide all this tooling for being careful who you share files with, while providing none of that to being careful about which applications I share data with, is a little bit disingenuous about the relationship between people and applications. People write and operate applications, so when I am sharing my data with applications, I am sharing it with people too. I just don't get to find out who or have any specific control over that.
tzs 7y ago
You could probably do something with access control lists and setuid/setgid. Take a set of programs that all should have the same set of accessible folders and the same set of inaccessible folders, and make them setuid to the same UID, and then add the appropriate entries for that UID to the access control lists for all those folders. The usual interfaces for manipulating ACLs are not very friendly so you'd want to have some kind of tool to set this thing up. Managing the ACLs, and managing the program grouping UIDs, and making it so things don't get regularly broken by package managers that don't know about this system is probably going to be challenging. What I'd like to see is someone make an access control system for Unix based off of the ideas from the old DEC PDP-10 operating system TOPS-10 file daemon system. TOPS-10 originally just had owner/group based access. Later, they added the file daemon access control system. The way that worked is simple: 1. If an access was allowed by the owner/group system, it went through normally. 2. If an access was NOT allowed by the owner/group system, and the new "use file daemon" flag had not been set by the caller, the accesses was denied. 3. If, on the other hand, the "use file daemon" flag was set, the OS sent a message to the file daemon describing the desired access, and asking the file daemon if it should be allowed or not. Whether the OS allowed the access or not was determined by the file daemon. In what follows I'm probably getting some details wrong, but the general idea is right. The way file daemon made its decision was by consulting a rules file containing access rules. The rules file was named ACCESS.USR. I don't remember if file daemon looked for that in the same directory as the file it was being asked about, in the home directory of the owner of the file, or what. The key idea is that the access rules for a file were in ACCESS.USR, NOT in metadata of the file itself. ACCESS.USR allowed for wildcards, so one rule in there could specify the access rights for a whole class of files--including files that did not yet exist. My recollection is that the rule matching could be based on the name of the file someone is trying to access (full or partial, with wildcards), the user and group that is trying for access (I believe wildcards were allowed here, too), and what program was being used. So let's say you wrote a game, and it wanted to keep a high score file. You could make an entry in ACCESS.USR that said anyone was allowed write access to SCORES.TXT if they were running EMPIRE.EXE. (Picking EMPIRE for my example in the hopes of summoning Walter Bright, since he probably remembers more details than I do about file daemon). Then just make sure to set the permissions on SCORES.TXT so that access by anyone other than yourself will fail, and make sure that EMPIRE.EXE sets the "use file daemon" flag when it tries to write the score file. This fits in well with the way users think about things. For example, let's say I've got public and private key files. My public key files have .PUB extensions and my private key files have .KEY extensions. It is easy to put a rule in ACCESS.USR that denies all others access to my .KEY files. If I do something that creates a new .KEY file, I don't have to make sure whatever tool created it set the ACLs...I just have to make sure I use a .KEY extension. It's a lot easier to develop and maintain a naming convention that reflects my security requirements and stick to that than it is to manage per file ACLs that reflect my requirements.

ufmace 7y ago

This sounds kind of like what Microsoft did with UAC in Windows Vista. As I recall, it was a terrible experience and everybody hated it. Seems like the trouble is that the huge installed base of applications have no accommodations for anything like that, which makes it awful to try to impose stricter permission requirements now. Even imagining how is kind of tough. How do you let some Python scripts, but not others, access certain directories, like the ones with your SSH keys? It would have to be built into Python, which may mean major changes to tons of packages. Ditto Ruby, NodeJS, Perl, PHP, and every other interpreted language out there. And how do you develop compiled applications in such an env? Suppose every new build would have to be signed with the expected permissions. But how would you let one internal package access a dir, but not some other one? More internal permission systems I guess?

IshKebab 7y ago

We need library level isolation, not just app level isolation (which desktop OSes don't even bother with). Fortunately there's some amazing work on supporting library isolation in WASM. There was a really good blog post about it recently.

srcmap 7y ago

In the old day, I used ZoneAlarm to alert me / block any app that was trying connect to any networks by default. Does anyone know similar solution for today's win10, Linux, Android environment? Win10's firewall is ok for blocking when configure manually. But it lacks the "alert" functionalities on any new app/connections requests.

StreamBright 7y ago

I absolutely agree with you. An OS should be many read only folders like /kernel /etc /bin that can be changed in an update process (that requires reboot) and folder where you give access to specific applications like /bin/ssh ro -> .ssh/id_rsa. Python process should not have read access to this folder by default at all. There are other solutions that you move all the credential access to a service that is accessed on a port by applications using tokens with different privileges. The current implementation of operating systems are pretty horrid, retrofit security all over. I think we are ready for a new OS era.

grumple 7y ago

Running everything in containers seems to make sense.

jbergens 7y ago

Windows have had locks for specific things for many years. They also created a new model with sandboxed runtimes för Windows Store Apps but those are not very popular. Yarn, a ja package manager, tried to forbid any code execution during installs. That may be a good idea. At least show a warning or require an extra flag before executing anything.