New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

20161018+1 reintroduces passwordless sudo for pi user even if previously removed #6

Closed
m-reiter opened this Issue Oct 19, 2016 · 19 comments

Comments

Projects
None yet
8 participants
@m-reiter

m-reiter commented Oct 19, 2016

By moving the entry for the pi user to /etc/sudoers.d/010_pi-nopasswd, passwordless sudo for pi is reintroduced even if it has previously been removed/disabled. I would consider that a security issue.

IMHO, the file should only be created if a) the original entry is still in /etc/sudoers and b) the user pi still exists.

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 19, 2016

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.

@Trapizomba

This comment has been minimized.

Trapizomba commented Oct 19, 2016

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

@m-reiter

This comment has been minimized.

m-reiter commented Oct 19, 2016

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.

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 19, 2016

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.

@m-reiter

This comment has been minimized.

m-reiter commented Oct 19, 2016

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.

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 19, 2016

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.

@m-reiter

This comment has been minimized.

m-reiter commented Oct 19, 2016

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... ;-)

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 19, 2016

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

@JimGaluska

This comment has been minimized.

JimGaluska commented Oct 19, 2016

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.

@DougieLawson

This comment has been minimized.

DougieLawson commented Oct 20, 2016

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.

@m-reiter

This comment has been minimized.

m-reiter commented Oct 20, 2016

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.

@DougieLawson

This comment has been minimized.

DougieLawson commented Oct 20, 2016

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

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 20, 2016

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.

@nenenes

This comment has been minimized.

nenenes commented Oct 28, 2016

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,

@dualcells

This comment has been minimized.

dualcells commented Oct 28, 2016

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

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Oct 28, 2016

@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.

@XECDesign XECDesign closed this Dec 1, 2016

@macmpi

This comment has been minimized.

macmpi commented Jun 1, 2017

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.

@XECDesign

This comment has been minimized.

Contributor

XECDesign commented Jun 1, 2017

@macmpi

This comment has been minimized.

macmpi commented Jun 1, 2017

Thanks for quick feedback: looking forward this upcoming update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment