3 ms·

Where else would you like to put them?

by tokenizerrr 10y ago

simula67 10y ago
How about /etc/username ?
- icebraining 10y ago
  And then you can't install a package because its name conflicts with the name of some user?
- tokenizerrr 10y ago
  Would the user still be able to write to that directory without bumping their privileges? If so, how does this help anything?
viraptor 10y ago
There are better places than directly in `$HOME`. One is some abstracted service like windows registry. Another is just separating the configs better, like `$HOME/.config`. Both are good ideas.
- tokenizerrr 10y ago
  `$HOME/.config` is a good idea, but doesn't help anything really. It's still within $HOME, and writable by any process that runs under the user. The Windows registry is just awful, and does not offer any actual protection that the filesystem cannot provide.
  - viraptor 10y ago
    I think you're wrong on both counts. Specifically: 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. 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.
    - tokenizerrr 10y ago
      > 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.
  - philh 10y ago
    $HOME/.config would somewhat mitigate against this exploit. A user running wget is much more likely to be in their home directory than in .config, and a hidden script file is less dangerous if there's nothing around which will execute it. This would still need fixing, but it would be a bit less dangerous.

Where else would you like to put them?

simula67 10y ago

How about /etc/username ?

icebraining 10y ago
And then you can't install a package because its name conflicts with the name of some user?
tokenizerrr 10y ago
Would the user still be able to write to that directory without bumping their privileges? If so, how does this help anything?

viraptor 10y ago

There are better places than directly in `$HOME`. One is some abstracted service like windows registry. Another is just separating the configs better, like `$HOME/.config`. Both are good ideas.

tokenizerrr 10y ago
`$HOME/.config` is a good idea, but doesn't help anything really. It's still within $HOME, and writable by any process that runs under the user. The Windows registry is just awful, and does not offer any actual protection that the filesystem cannot provide.
- viraptor 10y ago
  I think you're wrong on both counts. Specifically: 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. 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.
  - tokenizerrr 10y ago
    > 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.
- philh 10y ago
  $HOME/.config would somewhat mitigate against this exploit. A user running wget is much more likely to be in their home directory than in .config, and a hidden script file is less dangerous if there's nothing around which will execute it. This would still need fixing, but it would be a bit less dangerous.