221–230 of 323 posts
Article points out Gitlab account olgired2017 ( https://gitlab.com/olgired2017 ). I think it will be interesting if GitLab shares his/her list active session details like ipaddress, browser, date and time from their site logs (profile/active_sessions).
Earlier quoted context omitted.
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…
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
Monitoring is also something that requires expertise, and therefor is something only companies are really going to benefit from. Individual users are not equipped to do this.
This is part of why I install my Python dependencies from downstream Linux distro repos. I never use virtualenv. If a distro is missing a package I need, it's a simple process to put it together, and the additional steps and checks built into the process stop close to 100% of these issues. Getting a human here also lets you do things like patch out telemetry or other anti-features. Software repositories without a hum…
Indeed. Plus this whole "install the whole python ecosystem for each thing you want to use" is insane.
This wasn't just for Python libraries, but also with OS packages (especially non-sanctioned RPMs). I've been very selective about what I install globally, and usually first reach for a VM or other virtual environment.
One big counter to this is when I want to make it a simple commandline tool to run. I have to enter a Virtualenv just to run my fancier `ls` command?
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 pr…
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-...
Earlier quoted context omitted.
Android isn't proprietary. On the other hand, Windows and macOS, which, as far as I am aware, also have this problem, are proprietary. Hence, I don't see why an argument like "unlike proprietary systems" is justified.
Windows and macOS have been pushing for sandboxes for quite a while as well, exactly to prevent this kind of behavior. Currently macOS is more agressive than Windows on this area, with Apple now requiring notarization for all software, which you can still bypass, but need to explicitly allow it.
Earlier quoted context omitted.
I agree it can be inconvenient but don't iOS and Android kind of show that for most users the experience can be just fine? For us devs we can still either open our systems or find better ways but I'd prefer the default to be more closed. I'd also prefer the default to be VM-ish. Right now I have 275 projects in my /home/me/src folder. Every one of them has at least a build process that executes code I have mostly not…
you could use some lightweight rootless containers: I wrapped bubblewrap in a small python-program parsing a YAML-configuration (which mirrors my hosts rootfs and provides "topical" homes: node, python, scientific stuff), but there is also something like toolbox: https://github.com/containers/toolbox/blob/master/README.md Note that you need to secure your X-Server also, especially when sharing your network-namespace.…
E.g.,
https://www.twistlock.com/labs-blog/escaping-docker-containe...
https://www.exploit-db.com/exploits/46978
Full virtualisation does far better, though I believe there've been exploits there as well. Yes, from 2015:
https://threatpost.com/xen-patches-7-year-old-vm-escape-hype...
Earlier quoted context omitted.
"Solid SELinux policy" is really the hard part there. When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ansible, I want ansible to be able to shell out to OpenSSH to use my keys. If I write custom Python code that calls gpg, I want that custom code to be able to load libraries that I've pip installed without the gpg subprocess being blocked from loading my keys. If…
If you are installing paramiko or ansible you know what you are doing. It should be end user conscious choice to give them access. You should not be prevented to give that access but also that access should not be granted without end user knowing it. You don't want to instal "some library, from somewhere" to have automatically access to everything on your machine. I also agree with all people that comment that it is…
You could argue that the user should know what they're doing, but then, drivers shouldn't crash cars, and pilots shouldn't crash aircraft.
Numerous elements of this problem are simply hard, perhaps impossible to resolve. If the problem is what Neal Stephonson called metaphor shear in "In the Beginning Was the Command Line", then the fundamental problem isn't technical, but that people generally are operating under a false mental model of what computers are, can do, and do behave.
Yes, "all models are false, some are useful". The utility of this one may be past its sell-by date.
Reminds me of the fraudulent scientific papers that get caught using really dumb fakes (e.g., microscopy pictures that are copies of one another re-zoomed and rotated); we catch the dumb ones, but presumably not all malicious actors are dumb, so there must be a lot more fraudulent work out there.
For that matter, isn't there a reasonable systematic way to catch out typosquatters simply based on text analysis? Any library name that's a short edit distance from a popular library should have been carefully reviewed from the start; there's no excuse for "jeilyfish" to have lasted more than a couple of days.