[gmueckl]

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]

This is pretty much the whole point of SELinux (and probably AppArmour)

[geofft]

How 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.)

[cyphar]

SELinux 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]

Directory 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.

[Conan_Kudo]

SELinux 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.

[segmondy]

I'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]

> Check if the file links to .bashrc?

That would seem to be the obvious right choice. What's the problem with it?

[MayeulC]

Mmm... 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).