4 ms·

> 1. It doesn't have to be writable for everything. The $HOME/.config gives a nice abstract separation of what's "mostly readonly configuration" and what's not.

> 1. It doesn't have to be writable for everything. The $HOME/.config gives a nice abstract separation of what's "mostly readonly configuration" and what's not. (home files, runtime data, etc.) While it doesn't buy anything right now, just separating the configs into a hierarchy allows us to do interesting things like system-wide notification/approvals of .config writes. It's not impossible in the flat world of "all dot-files live in $HOME", but it could make generic solutions easier. If you're running as a regular system user, there is nothing you can do. All files you create are owned by you, readable by you, and modifiable by you. If we're talking about some kernel enhancements that do not yet exist, then yes, just about anything is possible. I was under the impression we were discussing things that are actually possible today on any old Linux install. > 2. Windows registry is just one implementation of an idea. While it cannot provide more protection than files at the moment, it does have ACL capabilities, so there's no reason a different implementation cannot extend this idea to checking process identifiers in some OS-specific way. For example imagine linux registry as a dbus service which can have calls filtered at selinux level. You can access /usr/bin/foo settings, /usr/bin/foo can read those settings, but /tmp/malicious/foo can neither read nor write them, even though it runs as your user. The linux filesystem also has ACL capabilities, much like the windows filesystem and registry. They all work on the user level, not on the application level. If the application /usr/bin/foo runs as my user, and somehow has some extra abilities than any other process running as my user, then I will just modify the memory of /usr/bin/foo after executing it, and leverage that process to access those "protected" files. This is a prime example of security through obscurity.

viraptor 10y ago
> I was under the impression we were discussing things that are actually possible today on any old Linux install. Both apparmor/selinux (process/label security) and fusefs (virtual per user/group/process filesystem) already exist. They're not put together for this specific purpose, but it just needs some userland glue, not kernel modifications. > They all work on the user level, not on the application level That's true for ACLs as implemented by the filesystem. Not for LSMs, which see both the application and the user (and many other things) > has some extra abilities than any other process running as my user, then I will just modify the memory of /usr/bin/foo after executing it No you won't. Extra abilities usually translate to suid, which you cannot ptrace. (default in kernel) Without extra abilities, you can restrict ptrace/memory access as well. (sysctl kernel.yama.ptrace_scope and others) Also, you're talking about a different threat model. I described a system where you can change `foo`s and `bar`s configuration, but `foo` cannot change `bar`s config without going through external process (with possible approvals). Sure, you could create a `foo` which can mess with `bar` if you want - you're allowed to do that. What this system protects from is someone taking over the `foo` process (via exploit in it) and modifying it at runtime - this is not security through obscurity - this is normal ACL enforcement where process / execution domain is defined by both the binary and the user who runs it, not just the user.
- tokenizerrr 10y ago
  > Extra abilities usually translate to suid If a binary has the suid flag set then it's not running as your own user, now is it? > I described a system where you can change `foo`s and `bar`s configuration, but `foo` cannot change `bar`s config without going through external process (with possible approvals). Sure, you could create a `foo` which can mess with `bar` if you want - you're allowed to do that. What this system protects from is someone taking over the `foo` process (via exploit in it) and modifying it at runtime - this is not security through obscurity - this is normal ACL enforcement where process / execution domain is defined by both the binary and the user who runs it, not just the user. Except it doesn't protect against that. Someone could exploit foo, have foo modify bar's memory and merrily carry on from there. Unless neither of these binaries run as the same user, or are getting sandboxed. But at this point we are so far from your initial point of simply moving files from $HOME that I'm not even sure what we're discussing.
  - viraptor 10y ago
    > Someone could exploit foo, have foo modify bar's memory and merrily carry on from there. I recommend doing some reading about LSM (selinux/apparmor) and/or grsec. This is exactly what they can prevent, even if you run foo and bar as the same user. > But at this point we are so far from your initial point of simply moving files from $HOME that I'm not even sure what we're discussing. Per-process / process group configs. You can (today, with tools you likely have already installed on an everyday linux distro) implement a basic system where the view into .config is limited per process and processes can read-but-not-modify settings, even though you (user who executes those processes) can read and modify. It's possible in flat $HOME, but hard. $HOME/.config makes it easier. Configuration as a registry service makes it trivial.
    - tokenizerrr 10y ago
      > I recommend doing some reading about LSM (selinux/apparmor) and/or grsec. This is exactly what they can prevent, even if you run foo and bar as the same user. Thank you, but I am aware about these technologies. And I just checked on my Ubuntu laptop, and I can modify the memory of any process running under my user. I'm talking about distros that are actually in use by people today, without any exotic modifications. I am aware there are ways to block all of this (making your life hell in the process) using tools that may or may not already be available, but that is a little bit more invasive than your initial suggestion of "Let's move files out of $HOME". And now you agree that moving them out of $HOME is not even necessary. So it seems you've changed your point from "Let's move all configuration files out of $HOME" to "Let's bake in a lot more security". Can't argue against that.

viraptor 10y ago

> I was under the impression we were discussing things that are actually possible today on any old Linux install. Both apparmor/selinux (process/label security) and fusefs (virtual per user/group/process filesystem) already exist. They're not put together for this specific purpose, but it just needs some userland glue, not kernel modifications. > They all work on the user level, not on the application level That's true for ACLs as implemented by the filesystem. Not for LSMs, which see both the application and the user (and many other things) > has some extra abilities than any other process running as my user, then I will just modify the memory of /usr/bin/foo after executing it No you won't. Extra abilities usually translate to suid, which you cannot ptrace. (default in kernel) Without extra abilities, you can restrict ptrace/memory access as well. (sysctl kernel.yama.ptrace_scope and others) Also, you're talking about a different threat model. I described a system where you can change `foo`s and `bar`s configuration, but `foo` cannot change `bar`s config without going through external process (with possible approvals). Sure, you could create a `foo` which can mess with `bar` if you want - you're allowed to do that. What this system protects from is someone taking over the `foo` process (via exploit in it) and modifying it at runtime - this is not security through obscurity - this is normal ACL enforcement where process / execution domain is defined by both the binary and the user who runs it, not just the user.

tokenizerrr 10y ago
> Extra abilities usually translate to suid If a binary has the suid flag set then it's not running as your own user, now is it? > I described a system where you can change `foo`s and `bar`s configuration, but `foo` cannot change `bar`s config without going through external process (with possible approvals). Sure, you could create a `foo` which can mess with `bar` if you want - you're allowed to do that. What this system protects from is someone taking over the `foo` process (via exploit in it) and modifying it at runtime - this is not security through obscurity - this is normal ACL enforcement where process / execution domain is defined by both the binary and the user who runs it, not just the user. Except it doesn't protect against that. Someone could exploit foo, have foo modify bar's memory and merrily carry on from there. Unless neither of these binaries run as the same user, or are getting sandboxed. But at this point we are so far from your initial point of simply moving files from $HOME that I'm not even sure what we're discussing.
- viraptor 10y ago
  > Someone could exploit foo, have foo modify bar's memory and merrily carry on from there. I recommend doing some reading about LSM (selinux/apparmor) and/or grsec. This is exactly what they can prevent, even if you run foo and bar as the same user. > But at this point we are so far from your initial point of simply moving files from $HOME that I'm not even sure what we're discussing. Per-process / process group configs. You can (today, with tools you likely have already installed on an everyday linux distro) implement a basic system where the view into .config is limited per process and processes can read-but-not-modify settings, even though you (user who executes those processes) can read and modify. It's possible in flat $HOME, but hard. $HOME/.config makes it easier. Configuration as a registry service makes it trivial.
  - tokenizerrr 10y ago
    > I recommend doing some reading about LSM (selinux/apparmor) and/or grsec. This is exactly what they can prevent, even if you run foo and bar as the same user. Thank you, but I am aware about these technologies. And I just checked on my Ubuntu laptop, and I can modify the memory of any process running under my user. I'm talking about distros that are actually in use by people today, without any exotic modifications. I am aware there are ways to block all of this (making your life hell in the process) using tools that may or may not already be available, but that is a little bit more invasive than your initial suggestion of "Let's move files out of $HOME". And now you agree that moving them out of $HOME is not even necessary. So it seems you've changed your point from "Let's move all configuration files out of $HOME" to "Let's bake in a lot more security". Can't argue against that.