I'd like to set a lockscreen password that is relatively easy to type. Currently, my system password is fairly complicated, and too much to type very frequently. I'd essentially like two tiers of security. The "difficult" system password makes access to sudo difficult, while the "simpler" lockscreen password prevents passing strangers from accessing the computer while at work, and prevents my kids from accessing my computer while at home. Is it possible to have a lockscreen password that differs from the system password?

Hello,

You may use the simple password for yourself and the difficult one for root ("sudo passwd" to change it). Then you should change your /etc/sudoers file to make sudo ask for the root password :

Code: Select all

# User "root" may execute any command as any user
root ALL=(ALL) ALL
# Members of group sudo may execute any command
%sudo   ALL=(ALL) ALL
Defaults targetpw  # Ask for the password of the target user
## Read drop-in files from /etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /etc/sudoers.d


Louis

louis94 wrote:Then you should change your /etc/sudoers file to make sudo ask for the root password

Thanks very much for the answer. That's a very interesting idea! However, are they any security ramifications with this? The Arch wiki says that setting `Defaults targetpw` (or rootpw) might make your computer less secure.

Warning: This is not intended usage of sudo. You are removing the capability of securing your server by removing the password from root.

Similarly, this comment says

Instead of using sudo's capacity to limit access by user you are exposing your root password to a number of users. You are also removing the capability of securing your server by removing the password from root

I don't totally understand all of this. At the moment, I have disabled logging in as root, so perhaps that is incompatible with targetpw/rootpw?

I'm not a security expert, but here is how I understand it. Take it with care.

Warning: This is not intended usage of sudo. You are removing the capability of securing your server by removing the password from root.

I think the intended use of sudo is allowing specific users to run specific commands as other users. This is why sudo asks for your password : the admin has allowed you to run certain commands as root. Maybe not all : she may not wish you change her password by running passwd as root.
Let's say you are the admin on a server. You wish user Penny can run command tux as root. So you use /etc/sudoers to allow Penny to run tux. Normally, she uses her password to authenticate. However, if targetpw is set, you need to give her the root password. So she may run everything.

Instead of using sudo's capacity to limit access by user you are exposing your root password to a number of users.

This comment is for Ubuntu users. In Ubuntu, all admins (members of group "admin" or "sudo" I think) are allowed to run any command as root using their own password. Even passwd. So every admin virtually knows the root password, which may be bad. Notice the commented answer does not talk about targetpw.

In a home environment where there is only one admin, I don't think using the root password and targetpw is a problem.

Louis

PS
Be careful ! You need to have set a root password before modifying /etc/sudoers, or you won't be able to run commands as root !

Thanks again for the quick reply. Apologies for the second quote, I got confused; I now realise it had nothing to do with what we were talking about.

Excellent comments. However, I've tested it, and I can see one potential security risk. It's now possible to log into my computer as root. I'm unsure of the real-world ramifications of this.

In theory, this means that attackers don't have to guess my username too. However, I have disabled ssh, so presumably they can only attack my system if they have physical access, where any kind of protection is moot anyway (my system isn't encrypted).

Well, in your previous setup your user password gave access to the root password. So there is no change here (an user name is much easier to find than a password : list /home, list permissions on any file in your home folder, list processes, ... try the name of the person being attacked).

Louis

It's more that the attacker can now log in with the username `root` rather than having to guess my username, but I presume that as long as SSH is disabled this is probably not very important.

https://wiki.archlinux.org/index.php/Se ... root_login

Using targetpw and sharing the root password is an additional security risk if (and only if) the sudoer is restricted in executing commands, because while he so far only maybe could gain privs for "sudo pacman -Syu", he now has a full blown rootshell access (and can thus do everything)

Please also take into consideration that all users with physical access to the machine (ie. can force a restart and interact w/ grub) they can easily get a rootshell anyway (by adding "systemd.unit=rescue.target" to the kernel parameters, ie. start into runlevel 1)

PS:
------
I've a underdeveloped code flying around here which takes a password parameter, grabs input and starts a random command ("screensaver") and unlocks after (blindly) entering the password parameter in a row.
In case of "major" interest, I could revisit it and make an AUR package.

It's however *NOT* "as good" as the KDE screenlocker, because the latter is now in the session keeping process, ie. if you manage to kill the screenlocker process from outside (or by X11 screenshots) it will exit the entire session implicitly.
Also it does not activate on idle or so (it's more like the "I play this movie and keep my nephew away from the system" usecase

luebking wrote:Using targetpw and sharing the root password is an additional security risk if (and only if) the sudoer is restricted in executing commands, because while he so far only maybe could gain privs for "sudo pacman -Syu", he now has a full blown rootshell access (and can thus do everything)

I don't have ssh enabled, and the single sudoer account has access to everything, so I guess it's moot then.

luebking wrote:Please also take into consideration that all users with physical access to the machine (ie. can force a restart and interact w/ grub) they can easily get a rootshell anyway (by adding "systemd.unit=rescue.target" to the kernel parameters, ie. start into runlevel 1)

I figured that if the computer is physically stolen, the attacker could simply take out the hard drive anyway. Or boot into a Live CD and read the hard drive.

luebking wrote:I've a underdeveloped code flying around here

Thanks for the offer. Since targetpw appears to have no security implications for my use case, I'm happy enough to stick with this.

I've tested targetpw for a few days, and it seems to work fine mostly. Specifically, I can independently set kwallet's password to something tricky, and kdesudo asks for root's password, too. However, there is a problem with programs that internally trigger a request for a password. For example, if I run gparted as a normal user, it asks for root permissions. The password required here is the "simple" user password, not root's password. Is there a way to make it ask for root's password, and/or is this a potential security risk?

I don't know how gparted raises its privileges, but apparently it does not invoke sudo then.
Check the process table when gparted asks for the password and look out for processes like kdesu or gksu or similar which hold "gparted" as a parameter.

This was the only process running for my user and not root:

Code: Select all

/bin/bash /usr/bin/gparted_polkit

It uses polkit - while that's weird. You're apparently on arch, I checked the polkit rule provided by arch for gparted and it says:

Code: Select all

    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>


so you should be asked for the root passwort, unless there's some local override.

Check /usr/share/polkit-1/actions/org.archlinux.pkexec.gparted.policy and look out for a /usr/local/share/... override.
(You need root permissions to access the files)

I'm not sure what you mean by "a /usr/local/share/... override.", but these are the contents of `/usr/share/polkit-1/actions/org.archlinux.pkexec.gparted.policy`. Looks pretty similar to what you posted.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>

  <action id="org.archlinux.pkexec.gparted">
    <message>Authentication is required to run the GParted Partition Editor</message>
    <icon_name>gparted</icon_name>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gparted</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
  </action>

</policyconfig>


Ah, that's because of /etc/polkit-1/rules.d/50-default.rules
Either remove that or your user from the wheel group.
(Be careful: i found bugreports that instead of asking for the root passwort, polkit just **** itself when you're not in wheel. No idea whether that's fixed)