511–520 of 534 posts
Earlier quoted context omitted.
Any interesting links to papers?
There's the work by Myers and Liskov which is quite central to the whole field: https://dl.acm.org/citation.cfm?id=266669 , there's Flume: https://dl.acm.org/citation.cfm?id=1294293 , DStar https://www.usenix.org/event/nsdi08/tech/full_papers/zeldovi... . More recently, on Android: https://www.usenix.org/system/files/conference/usenixsecurit... . And this (disclaimer: I'm the main author): https://link.springer.com/c…
The real problem is that any app I run accesss all files I own with equal permissions. App1 and App2 shouldn’t write their data to my home, or read each other’s data, or, please, be able to write each other’s data. A video game can read my tax forms. WTF. Mobile & tablet OSs solve this. Everything has to follow. Until then, basically every app should run in a docker container. Then it can do what it wants.
Earlier quoted context omitted.
Has this ever been a problem in practice for you or is it all theoretical? The tradeoff doesn't seem worth it to me.
Not the OP, but think of all the times your computer caught viruses or got hacked.
Earlier quoted context omitted.
You can use https://github.com/JK3Y/asepsis to have them all redirected to one folder. So not have them in every folder. That’s forked from the project originally being by TotalFinder’s creator as far as I know.
A couple of caveats: one, it seems to inject into other processes, which is not something you want to do with System Integrity Protection enabled, and two you need to run touch ~/.no-asepsis-os-restriction to make this work :)
Earlier quoted context omitted.
su - also works. Indeed the capability exists (unix/linux pioneered it?), but it relies on manual containment by the user. It should be automated, with prompts at install or execution time, like on mobile OSs. An idea is each file should have its own user, basically, with both relative and absolute file creation/modification permissions. If you run an arbitrary executable as a user there's great security risk since i…
There are differences between the apps I use on my phone and the programs I use on my PC. I don't trust many of the apps on my phone (all of Google, FB, messaging, etc). I trust the open source apps (example K9 email) and I'm replacing proprietary apps with open source ones. I trust almost all programs I use on my PC, which I install with apt-get from Ubuntu or other open source PPAs (no snap, no flatpack). There are…
1. Desktop OS's have awful security
2. Therefore you're VERY careful about what you install
3. Because you're VERY careful about what you install, you don't need the extra security, it would only be an hassle.
Earlier quoted context omitted.
Not the OP, but think of all the times your computer caught viruses or got hacked.
I'm thinking of zero. Zero times, in my life. As the old saying goes, common sense is the best antivirus. Although I did get the ask toolbar once...
Earlier quoted context omitted.
AppArmor and SELinux address this problem. But -- speaking from experience -- they are painful to use; most users prefer convenience over heightened security.
They're painful to set up yourself, but that's pretty much true of all current sandboxing approaches. If you just let your distro do it and follow their conventions it you barely notice.
Agreed.
Earlier quoted context omitted.
If you do not rename files while holding their open file descriptors there's no guarantee that you are renaming the file you just wrote to.
There is no guarantee of that if one does retain the open file descriptor.
fstat the fd, get st_dev and st_ino.
rename
stat the new name. Compare st_dev and st_ino.
If the value matches, you renamed the right file. If it does not match, you renamed a wrong file. Without holding the fd, it is impossible to know if it is the right file.
Earlier quoted context omitted.
There is no guarantee of that if one does retain the open file descriptor.
before rename: fstat the fd, get st_dev and st_ino. rename stat the new name. Compare st_dev and st_ino. If the value matches, you renamed the right file. If it does not match, you renamed a wrong file. Without holding the fd, it is impossible to know if it is the right file.
Earlier quoted context omitted.
before rename: fstat the fd, get st_dev and st_ino. rename stat the new name. Compare st_dev and st_ino. If the value matches, you renamed the right file. If it does not match, you renamed a wrong file. Without holding the fd, it is impossible to know if it is the right file.
"you renamed a wrong file" shows that "there's no guarantee that you are renaming the file you just wrote to".