On 2 May 2018 at 10:08, Kamil Dudka <kdudka@xxxxxxxxxx> wrote: > On Wednesday, May 2, 2018 3:46:34 PM CEST Stephen Gallagher wrote: >> On Wed, May 2, 2018 at 6:44 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: >> > On 2.5.2018 15:30, Stephen Gallagher wrote: >> > > Does anyone see a reason not to prioritize ~/.local/bin over >> > >> > /usr/bin? >> > >> > > Yes, if a user's account is compromised (or any service running as >> > > them), it's REALLY easy to drop faked tools into a user-private >> > > directory and override critical system tools (like replacing 'bash' with >> > > a keylogger). >> > >> > If user's account is compromised, user's PATH can be changed. IMHO the >> > provided argument is not valid. >> >> There are a lot of ways where their account can be compromised without >> having complete session access. If they're running a web-connected >> application as their user, that application could be compromised to write a >> file to disk. If that file can now supersede the system copy, they have now >> escalated the degree of the compromise. > > You have two choices: > > 1. Either you allow users to easily install software to their home directory. > If their user account is compromised, an attacker can install some software > they do not want to install, but it still affects their user account only. > The issue is where they do not know they have installed software to their home directory. This leads to the problem outlined in https://xkcd.com/1200/ where the user account is more precious than having root. > 2. You do not allow users to easily install software to their home directory. > In that case, they will install questionable software using sudo, which > gives it root privileges and affects all other users on the system (and > possibly other systems reachable through a trusted network). > Which most users will do anyway because every stackoverflow and software install says you have to do a 'curl | su -' or a 'sudo pip/gem/etc install' 3. You do not allow users to easily install software to their home directory. You do not allow them to get sudo access either. They have limited access on that box because they may need to do certain tasks which are audited and controlled. [This is the usual case for server systems because you have to follow rules which are dictated outside of either the system admin, user or OS manufacturer.] What happens then is that users do not want to be on that system and will set up their own system. > Which of those choices is more secure? > None of them is more secure because security is an overloaded template versus a single term. Each of those has its own threat analysis and may have reasons to be done in one place or another. Most of those may be dictated by outside forces. Trying to say if one is more secure is like saying "Which one is more colour? Red, blue or green?" > Kamil > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
