4 ms·

> 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

> 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
    > And I just checked on my Ubuntu laptop, and I can modify the memory of any process running under my user. Yes, you can. And that wouldn't change. That's not the point of the modification. But you're wrong saying this is exotic or would make life hell. You're running Ubuntu. This is already happening and it seems you're not even aware of it. Run `apparmor_status` and see what profiles are already enforced. I'm pretty sure that you have /usr/bin/evince listed in there. (it's installed by default) Now, try to open any pdf in evince and save a copy to `~/.ssh`. Or `~/.mozilla`. Or `~/.config/chromium`. Or `~/.gnupg`. You have access to those directories as a user - so guess why it's failing? Apparmor does exactly what I described. You can still modify the memory of evince - do whatever you want to it, I'll wait. But it won't change the result - you can't write to those directories from evince itself. You can still save that pdf as anything in your $HOME however. I didn't change my point. Security is not binary - there's no secure and insecure, but a gradient in between. Moving configuration out of home is one step of the big process which will make better security easier to apply.

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
  > And I just checked on my Ubuntu laptop, and I can modify the memory of any process running under my user. Yes, you can. And that wouldn't change. That's not the point of the modification. But you're wrong saying this is exotic or would make life hell. You're running Ubuntu. This is already happening and it seems you're not even aware of it. Run `apparmor_status` and see what profiles are already enforced. I'm pretty sure that you have /usr/bin/evince listed in there. (it's installed by default) Now, try to open any pdf in evince and save a copy to `~/.ssh`. Or `~/.mozilla`. Or `~/.config/chromium`. Or `~/.gnupg`. You have access to those directories as a user - so guess why it's failing? Apparmor does exactly what I described. You can still modify the memory of evince - do whatever you want to it, I'll wait. But it won't change the result - you can't write to those directories from evince itself. You can still save that pdf as anything in your $HOME however. I didn't change my point. Security is not binary - there's no secure and insecure, but a gradient in between. Moving configuration out of home is one step of the big process which will make better security easier to apply.