Il giorno Mon, 10 Apr 2017 15:17:46 -0700
Rick Moen <rick@???> ha scritto:

> Quoting Alessandro Selli (alessandroselli@???):
>
> > 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: dhatarattha@???
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9