20161018+1 reintroduces passwordless sudo for pi user even if previously removed about raspberrypi-sys-mods HOT 19 CLOSED

I have scripts that automatically updates and configures my Raspberry Pis. I worked to make these scripts run un-attended. This update broke that functionally by making me acknowledge the message. I wanted to restore my scripts ability to run unintended, yet I did not want to completely ignore apt-listchanges messages. For whatever reason, I could not get any of the apt-listchanges environmental variables to work.

After playing around with it for a while, I found this solution:

sed -i 's/frontend=pager/frontend=text/' /etc/apt/listchanges.conf
apt-get update
apt-get upgrade -y
sed -i 's/frontend=text/frontend=pager/' /etc/apt/listchanges.conf

This allows me to see the messages scroll by, but doesn't pause the script.

The second 'sed' is optional. It just restores the config file back to its original content.

Please reply if you have a better solution.

from raspberrypi-sys-mods.

The two conditions you suggest are good, but not entirely practical right now. As a general rule, maintainer scripts shouldn't fiddle with conffiles, so there is no good way to install the file conditionally. Perhaps it should've been done in this case, since there is a good reason for it, but now it's impossible to tell a system that had the NOPASSWD line removed by the user or the previous package.

I think the best we can do now is add a NEWS entry. Then the users who claim to be concerned about security have no excuse to be unaware of this change.

from raspberrypi-sys-mods.

Agree! I will "pass" this update... A lot of my Raspberry facing internet...

from raspberrypi-sys-mods.

Re distinguishing between line being removed by user or by update: I guess if /etc/sudoers.d/010_pi-nopasswd does not exist it's safe to assume the line was removed by the user. If you're quick, most people will probably not have updated yet.

As for those that already did, I agree there's no way to fix that situation.

Is a NEWS entry displayed during the upgrade? If not, I'd recommend putting the info somewhere that ensures the user actually sees it.

from raspberrypi-sys-mods.

If apt-listchanges is installed, the NEWS entry is displayed. apt-listchanges has been included in the stock images a while ago.

I can add the check that if we're upgrading from a version that's earlier than 20161018 AND the entry doesn't exist in sudoers, the line in 010_pi-nopasswd gets commented out.

from raspberrypi-sys-mods.

Cool, I wasn't aware of apt-listchanges - it wasn't installed on my Pi 3 based off 2016-03-18-raspbian-jessie.img.

Your suggestion sounds sensible to me. I'd also make sure that people who already upgraded get shown the NEWS information during the next update.

from raspberrypi-sys-mods.

Some testing and tweaking later... 0e39b6a

People without apt-listchanges won't see the message.

The issue should affect people upgrading from a version older than yesterday's.

The NOPASSWD entry takes effect in either case when it's installed rather than upgraded (that's why it's there in the first place). In the future I can add a debconf prompt to ask if the user wants this.

Before I upload it, let me know if you see any issues here or have further suggestions.

from raspberrypi-sys-mods.

Looks good to me. I think it would be even better if displaying the message didn't depend on apt-listchanges since it seems to be a relatively recent addition to the standard image but I don't know enough about .deb packaging to tell whether that's even possible.

I think prompting in future versions is a good idea but I might be a bit more paranoid than the average Pi user... ;-)

from raspberrypi-sys-mods.

I think this is as fixed as it's going to be for now. Thanks again for reporting this.

from raspberrypi-sys-mods.

The changes in the latest *.deb file are 100% insane. It introduced a security exposure on every one of my Raspberries.

You can't replace a line in /etc/sudoers with a new file. Replace the whole /etc/sudoers file then apt-get will ask me if I want to install the changes and I can reject them at that point.

I've had to go round every machine removing the new rogue /etc/sudoers.d/010_pi-nopasswd file to restore my secure environment. I don't want NOPASSWD for any sudo users, it's a risk for an internet exposed machine.

from raspberrypi-sys-mods.

In principle, I'm with you there, Dougie, that's why I opened this issue in the first place. However, the latest eb should only have introduced the NOPASSWD entry if you still had it in your /etc/sudoers file. Otherwise, it should have been commented out in /etc/sudoers.d/010_pi-nopass.

Personally, I think including a directory to which newly installed packages might write without me even noticing in /etc/sudoers is a bad idea and have commented out the respective line.

from raspberrypi-sys-mods.

The directory was already there. The bigger problem is putting a new file in there that negates my security changes.

from raspberrypi-sys-mods.

You can't replace a line in /etc/sudoers with a new file. Replace the whole /etc/sudoers file then apt-get will ask me if I want to install the changes and I can reject them at that point.

Why not? That's exactly what sudoers.d is for. Debian packages shouldn't fiddle with conffiles they don't own. We can't, or rather shouldn't, replace the whole file. If it belong to another package, apt will complain. Purging the package will remove the sudoers file and leave it completely broken. Diverting the file would make us miss Debian's own updates to the file and won't ask you to approve the changes first. Associating a file with the package and sourcing it from the stock sudoers file allows the change to be removed when the package is removed and also keep getting upstream changes from Debian. Now neither 010_pi-nopasswd nor sudoers will change without you knowing about it.

The whole reason for this change is that it wasn't done correctly in the first place. There was a change that was not associated with any package. The image was shipping with a modified conffile, which messes with Debian's own management of that file. Now if you say 'I want stock raspbian', you can purge our modifications without leaving cruft behind (as far as this package goes, anyway). We have only swapped one long term security issue described above with a temporary one that's easily addressed by the user. I don't like it any more than you do, but it was the right thing to do in the long run.

Same goes with pkexec. Everybody knows about sudo, but perhaps not many people know that pkexec also grants them root access (albeit with the user's password). Previously, that change was 'hidden' and not associated with any package. Now it's a part ui-mods and can be purged.

You would only be affected by this if you updated during the ~12 hour period that the +1/+2 versions of the package were up and have previously removed the NOPASWD line and didn't check the changelog and didn't read the postinst output.

Everybody else sees a description of what happened, so they know about the change, but are not affected by it in any way.

Some people will not have apt-listchanges installed and might be unaware of the change, despite the postinst script saying that it is making changes to the sudoers file. I don't know how anyone can say they're concerned about security without at least glancing at the changelog and NEWS files. Although I take responsibility and try to address the issue, it is not 100% on the maintainer.

from raspberrypi-sys-mods.

I'm fairly new to Linux and the R-Pi . I loaded the current build of raspian on my V1 R-pi this evening and got the NOPASS message. Since I am setting up this R-Pi to work on the internet I gather that this change has a major affect on my security. IE it will allow almost anyone access to the root user (sudo? or su - ?) without a password. Is this correct or mostly correct? If so how do I secure my sudoers file(?). I also have the problem of not knowing exactly what a sudoers is although I figure it has to do with the privs a user has.

Still learning,

from raspberrypi-sys-mods.

nenenes have you read the sudoers section on https://www.raspberrypi.org/documentation/linux/usage/users.md ?

from raspberrypi-sys-mods.

@nenenes That's more of a question for the forum.

This update should not affect you at all, since you didn't update within the window where it made a difference. The default install already gives the 'pi' user root access and the default password is weak.

If you connect your pi directly to the internet without changing your password, bad things will happen. At a bare minimum, set a secure password. You should do more than that if you really want to secure the default install, but that's really outside of the scope of a github issue comment.

from raspberrypi-sys-mods.

Sorry to reopen, for a reduced-scope of the problem discussed here, but I'm not clear why this file is added at all if pi user simply does not exist on the system.

One may intend to use this great package to build & configure a custom system that has no pi user at all: wouldn't it make sense no pi user related changes are applied then, and in particular /etc/sudoers.d/010_pi-nopasswd is not created ?

Thanks for consideration.

from raspberrypi-sys-mods.

from raspberrypi-sys-mods.

Thanks for quick feedback: looking forward this upcoming update.

from raspberrypi-sys-mods.