[IDEA] Simple, but powerful security system

English Open Chat
#1

Firstly, I’m not an security expert. I’m only long-time Linux user and C/PHP/JS programmer.

I have an idea how to protect user configuration. There is, of course, SeLinux, which could protect per-application access to files, but it isn’t bundled in many distribution, because vendors decided it’s too complicated. And yet - OpenSUSE could have many positive things, if implement it. Mostly… It will act like PolicyKit, so OpenSUSE won by standardization of mechanism, which protect user config.

The base idea is simple… Create - for each user - additional user with different home directory and UID. Both users will belongs to the same group, so hack is to set read permission to our user of additional user’s home directory, but not write. Programs could read files from this home directory and could trust content won’t be changed by unauthorized operation.
User could change config in described new home directory, by admin rights (sudo, admin file manager protocol or other mechanism), fish or sudo (but it requires to set password for described user) or by new daemon, started on user login and working with rights of second user (with secured home). This daemon could be like PolicyKit, but uses private DBus session (newly created Unix socket, to which could only writes/read user’s program). Each program, installed in system by package manager, could install new program, which be automatically started by DBus on request. And these programs could writes in protected home directory.

This idea doesn’t protect from mess config files from one program by daemon of other program, but if user installs programs by package manager, it is still security risk, right?

Program should be changed in one, simple way - read configuration from protected home and… allow to set option to include configuration form normal home directory. For example, I present example proxy configuration of web browser:
In protected home:
[proxy]
Address=read_from_user_home
Port=read_after_this_text:8080

In not-protected home:
[proxy]
Address=http://some_site

But more important is setting in protected home.

Of course - some program could debug our program and change it’s memory directly, but this is a thing, somebody should solve.

#2

Protect or, “freeze” the user’s configuration?

  • If you link the “protected” user’s ~/.config/ directory to the parallel user’s ~/.config/ directory then, the ability to change the configuration will be nullified.
  • What’s with the content of ~/.local/share/ ?
#3

If you missunderstood my request, sorry. English is not my native language.

I don’t suggest to link any directories. Only to offer applications to store sensitive data in protected user directory, by special daemon. Read operation is not restricted expect only one (or two if you get in mind created to accomplish my idea) user can read configuration.

For example Firefox will offer daemon, installed by Firefox package. Firefox will read configuration from protected home, when started. When there’s word read from normal home in configuration, Firefox will read settings marked with that word from normal configuration (normal user home - writable).

When user opens Firefox configuration dialog and change some settings, which isn’t stored in normal home, Firefox asks daemon our daemon to communicate with daemon installed with normal Firefox package. Our daemon will start Firefox daemon via DBus activation and Firefox daemon will override settings. That’s all. That’s feature isn’t backward compatible, so it force developers to fix/match applications.

#4

@dcurtisfra :
About linking directories. This brings me to new idea. Why not protect ~/bin, autostart, file type association and desktop entries (menu for example)? On login process, special daemon will sync these directories with related ghost keep in protected home. Results will be saved into additional directory and present to user, so user can read information (for example) about desktop entries in autostart or menu, select which to preserve and daemon calculates changes made by user and updates ghost in protected home. DE or user won’t run malicious autostart program, for example.

This requires to modify KDE, GNOME and other DE to read given directories from protected home, instead of normal and to request daemon to change content of ~/bin, autostart, etc. in protected home, when user request.

Also program to update xdg menu should also be integrated, so user will be asked, when some software request to update menu. User could decide to not modify the menu (some software could change firefox.desktop to run virus, for example and my solution maybe will protect this kind of attack).

Sync could be made also by fnotify.

#5

@Lachu:

You seem to be worried about user applications overwriting and/or changing user’s configuration files.

  1. Applications which have been patched and/or updated often need to modify the user’s configuration files because, the changes made to the application have changed the format and/or syntax of the user’s configuration definition.
  2. The big advantage of Open Source is that, the code can be inspected by everyone. Therefore, the chances that, an Open Source application will begin to unnecessarily meddle with a user’s configuration definition are extremely small – and, I’m fairly certain that, as far as Open Source is concerned, this is an extremely rare case. The same can not be said about Closed Source applications …

Another issue, which is often overlooked, is, the templates used for example by Office applications:

  • OpenOffice and LibreOffice (and, in the past, StarOffice) offer the possibility for templates to be stored in a directory where only the System Administrators can change the contents – the Closed Source #1 in that area, AFAIK, still believes that Company templates are a “personal thing” …

[HR][/HR]Bottom line:IMHO, the protection of a user’s session configuration definitions is, at least for the case of Open Source, not a critical issue and, it’s, IMHO, not about to be an issue …

#6

I wrote about DBUS daemon similar to PolKit and allows applications to deliver own. We can also provide generic daemon, which allows to override config by application created it. This daemon will be simple - it reads app path from /proc, compares with string stores in db. Created new config directory, when application isn’t registered. Override config files, selected by app owning that file, when it have access to it (without asking user for password/permission). I mean that this isn’t too complicated to update config file.

#7

Recommend take a look at

Qubes - isolated installed applications
Firefox Lockwise - Web browser based solution to store credentials and files in the security context of the User logged into the browser (not the system or other)
AppImage, Flatpak, Snap - Self-contained, cross-distro distribution of apps. When the app is completely self-contained, it frequently will do everything including storage within its own file tree.
Docker, LXC and other containerized technologies - A more technical approach than AppImage, Flatpak and Snap… But sharing many of the same benefits and drawbacks as approaches to isolated applications and processes.

These suggestions also keep things simple, unlike your approach which appears to mix different systems together, ie system authentication/authorization, application, storage, etc, each of these suggestions tend to be self-contained which means less dependencies and complex integration with other systems.

If you want to try to propose a new security approach, it would probably be helpful for you to do some research into existing and new approaches to securing systems… it’s useful to have coding knowledge because it can be essential to better understand systems, but you can’t go far if you don’t acquire some knowledge of systems as well. If you can understand how these suggestions work, and add that to acquiring knowledge about AppArmor and SELinux, you’d probably generate some interest, but until then proposing something as better when not knowing what exists already is kind of tough.

BTW -
SELinux is possible in every distro, I don’t know that there is any exception and that includes openSUSE… It’s only that openSUSE implements AppArmor instead of SELinux by default because it’s more suitable for typical openSUSE usage. And, since AppArmor security is often if not mostly within the context of the User running the application, there’s already a strong connection between User security context and how secure applications are run. If you think that security should be different, it’s likely a disagreement with the application’s authors how the app is written, nothing more.

TSU