Il giorno Mon, 10 Apr 2017 15:17:46 -0700 Rick Moen <r...@linuxmafia.com> ha scritto:
> Quoting Alessandro Selli (alessandrose...@linux.com): > > > IMO, using root's password in those same cases is the worst possible > > password use case. One thing is your non-privileged user's password > > being captured when you mount an external drive, a different thing is > > giving away root's password performing the same trivial task. > > You might have missed my point that your suggestion makes that > 'non-privileged user's password' privileged -- such that every time you > use it in any situation, you are exposing a privleged password. Which > I deem very undesirable. You might have missed my point that your use of *superuser* password when unneeded exposes that privileged password when it can easily be avoided in serveral ways, that either expose an unpriviledged password or does not require any. >>> but it also has a secondary use to escalate privilege to root. >> >> Just like using su does. > > 'su -' does of course escalate (obviously), but _not_ as a secondary use > of an otherwise non-privileged login. Right. It "only" exposes the system's *superuser* password. > But I think the point should be > clear, and I don't care to keep re-discussing this point. > > Anyway, I'm glad whatever you do works for you. I did not argue that my way works and other people's does not. I'm only stating the obvious: using the root user's password for simple tasks that are easily configured in many alternative ways to work without requiring the user to type the superuser password exposes the most critical system password to be recorded/intercepted/glanced etc. >> Needing to type it just to mount an external drive increases the >> chances it will be used many times when easily avoidable. > > As already mentioned, this does not describe my experience. So what? Do you adopt security measures to counter vulnerabilities or neutralize attack vectors only *after* you personally suffered a security breach? >> This too would be a better solution than having to use su to just >> mount external drives. > > I do not concur, because IMO mounting/umounting is, in the general case, > security sensitive and ought to be treated with caution, which includes > not permitting arbitrary mounts/umounts by unprivileged users. sudo does permit selected users perform selected operations as another user. When it's configured to allow any user perform any task as the superuser than it's been abused. But assuming that the possibility of sudo to be misconfigured and abused is a valid point to argue against it's use is like arguing against setting any password to the superuser because it's possible that people set a weak password on that user. > But I > think the point should be clear, and I don't care to keep re-discussing > this point. > >> This is precisely the reason I suggested using sudo, which allows >> fine-tuning who gets to do what as another user. > > IMO mounting/umounting is, in the general case, security sensitive and > ought to be treated with caution, I agree, this is exactly the reason I think mounting/unmounting external devices should be either configured in /etc/fstab or under sudo or some other secure mechanism. There is however no connection between the fact that mounting devices is a potential security sensitive operation and the fact that the more often a user has to type the root user's password (expecially when unneccessary) increases the chances that this password is captured by a third party. > which includes not permitting > arbitrary mounts/umounts by unprivileged users. sudo can be used to allow only some selected users to perform mountig/unmounting of some selected drives onto selected directories. The implication that use of sudo per se exposes any unprivileged user to perform "arbitrary mounts/umounts" is baseless. The fact that administrative tools can be misconfigured and abused does not prove that those tools are bad for security, otherwise one could well argue against the use of each of them, starting from PAM and ending with Kerberos. -- Alessandro Selli http://alessandro.route-add.net VOIP SIP: dhatarat...@ekiga.net Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
