-
-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tunables for file formats? #525
Comments
No, this is not a good solution: a program is not legitimate to open a file based on its extension but based on its location. It is why all locations should be labelled. Such a solution would also be a security issue as it is quite obvious for some other programs to simply rename a file to have the right extension. Whereas, when you give access to a directory, they cannot escape it at all. It would also be a maintainability hell:
The solution to improve the current setup that is not perfect, is prompting: https://discourse.ubuntu.com/t/ubuntu-desktop-s-24-10-dev-cycle-part-5-introducing-permissions-prompting/47963 |
The reason for my suggestion is that a lot of profiles only have write access to user directories that a lot of other profiles also have write access to, like Downloads or Documents. So, if a user wants to download a sensitive file from a web browser or from a different app, they would normally have to resort to saving that file in a weird directory if they don't want that file to be readable by other programs (like, in .config/ or .local/share/ which usually are only read/writable to one profile). So, how about adding a private user directory for each app profile, in e.g. ~/Private/Program?
Could you clarify? Do you mean that a program can only read/write to /**/*.jpg could they rename ~/.zshrc to something.jpg to be able to read it? I must be misunderstanding |
I do something similar. I don't use the standard document directories and have a separate directory for every program. For example, if I write a document and send it in an email, I move the document from LibreOffice's directory to ThunderBird's directory. It's PITA. IMHO, multiplying directories isn't a good solution. The best solution is the so called PowerBox GUI. In principle, it's possible to create a privileged service which updates AppArmor profiles and is driven by such a GUI. |
I wish this was a part of the XDG spec. Firejail does this with the private folders but IIRC (and please correct me if I'm wrong), it clutters the home directory by creating the folders directly there rather than in a proper sub directory. This should really be standardized somehow. I'm also now doing this manually with overrides, in ~/AppData rather than ~/Private because I think that the application's private user files should still be accessible to the file manager. Prompting is great but it doesn't really solve the problem, in my opinion. |
Yes, but adding permissions to only open/write files based on their extensions enhances security. For example, the
Yes, true. But if I have the choice between
I would opt for the second option.
I think the the list of extensions as used by Morfikov for, e.g., mpv, vlc, okular is a very good start. This lists should hardly change, the maintenance burden should therefore be minimal.
The Libreoffice profile from Morfikov (which originally comes from Canonical) has been in use in Ubuntu for years. Access to cache/lock files is still possible.
Again, the LibreOffice profile on Ubuntu has been in use for years. It seems that it hasn't caused problems. Besides, security issues by deleting/manipulating files for which an application should not have any access is even more a security issue. |
Hum, I may change my mind on this. Can you open a PR that would create a file in We should however document how these extension name should be used. Something like:
Also, I would like to note: even if the sandboxing tool (flatpak/snap) are far to be perfect, correctly handled they can provide more security (in more separation) than confinement that is more suitable for app that you can't confine easily (ie: that have too many interaction with other programs). |
I created it on #543.
Even better should be to use apparmor alongside a namespaces sandbox manager, as both have their shortcomings and having extra protections is always good |
I'd love to do this, and I have a file that is nearly finished. However ...
... |
You are right. This structure need to fully be revisited. However, I am still looking for a solution that would please everyone and that would be technically compatible with all security objectives. Currently we have the following positions (that are all legitimate tbh):
|
Yes, it's difficult. But whichever solution comes out of this, I think that removing the A similar logic would apply to |
Thanks! However, it's not comprehensive enough as capital letters are not taken into account. The (still half-baked) solution I had mind (which is largely copied from the Canonical profile for LibreOffice and from Morfikow) is:
Yes, but this can lead to new problems (example). |
A way to further confine a few tools, I think, would be to add tunables for file extensions. For instance:
@{document_formats}
would containdoc docx odt pdf
etc., and then we could restrict e.g. the libreoffice profile to only read and write to files that have the whitelisted extensions, rather than every file.The text was updated successfully, but these errors were encountered: