3 ms·
This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious
by gmueckl 8y ago
This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers). How can we distinguish between those cases?
- briffle 8y agoThis is pretty much the whole point of SELinux (and probably AppArmour)
- geofft 8y agoHow does SELinux or AppArmor distinguish between those cases? More interestingly, how can it tell that VSCode spontaneously editing .bashrc is bad, but doing so in response to user input is good? (There are capability-based systems that permit distinguishing between these cases, but to my knowledge SELinux and AppArmor don't support this.)
- Conan_Kudo 8y agoSELinux labels users and domain transitions, so it's "technically" possible to do so, but I see that incredibly rarely. I don't think AppArmor has such a facility. It wouldn't make sense, given that AppArmor doesn't know these things like SELinux would.
- cyphar 8y agoSELinux and AppArmor would allow you to specify that your text editor is allowed to edit .bashrc, but some random other program isn't. But I agree with you that this is not really a useful security feature -- you'd want something where a program has to be explicitly granted permission rather than some programs being able to do things that others can't (because then any attacker will just spawn "vi -c 'bad payload'" to get around the restriction).
- jniedrauer 8y agoDirectory trees and files have a security context (etc_t, user_home_t, and so on), and there are rules governing which application contexts are allowed to access or modify which security contexts. It doesn't cover every edge case, and it can be frustrating to deal with things like local docker development. But the added safety is absolutely worth it to me.
- segmondy 8y agoI'll just make a file link to .bashrc and call it /tmp/foo.png, what are you going to do? Not open links? Check if the file links to .bashrc? If an image manipulation software wants to open .bashrc, allow it. If it has permission to write to one, so be it. If .bashrc is such a security nightmare, then perhaps the issue is that programs can write to it. Remove the write permission. Perhaps a security model where restoring permission asks for password.
- int_19h 8y ago> Check if the file links to .bashrc? That would seem to be the obvious right choice. What's the problem with it?
- MayeulC 8y agoMmm... This is a random idea, but maybe this could be supported trough filtering files by mimetype. Gimp would only get access to image/* (not sure it needs something else? Adapt in the case it does). Of course, this requires adjusting the current development workflow (maintain a list of filetypes needed, for example).