Bug 8536

Summary: Building sudo with PAM results in unusable sudo
Product: buildroot Reporter: nroach44
Component: OtherAssignee: unassigned
Status: RESOLVED WONTFIX    
Severity: normal CC: buildroot
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Host: Target:
Build:
Attachments: sudo.pam LDAP patch

Description nroach44 2015-12-17 10:00:50 UTC
As the title, when building an image with both sudo and PAM results in sudo denying all requests.

If you comment out the PAM section in sudo.mk everything works as intended (minus any PAM integration).

I only have one file in sudoers.d that contains:

%sudo	ALL=(ALL) ALL

otherwise I don't have any PAM or sudo configuration

I'm building for a SAMA5D3_XPLD (cortex-a5) board with linux 4.0.9 on latest git, with a custom ct-ng toolchain (that otherwise works)
Comment 1 James Knight 2015-12-17 16:43:04 UTC
I'm not a PAM expert, but I assume if you're integrating PAM support into sudo, I believe it requires the respective PAM configuration for sudo to work (/etc/pam.d/sudo). If anyone knows that this is not the case, I'd be interested to know.

Trying to reproduce, building with "--without-pam", I can configure a default user to perform sudo operations. If I build with "--with-pam" and I do not have "/etc/pam.d/sudo" configured, all requests are denied. If I use the "--with-pam" build with "/etc/pam.d/sudo" configured, it works fine. Is this what you are experiencing?

If integrating PAM support into sudo requires PAM configuration (ie. cannot fall back onto just sudo configuration), I'm curious if you have a desired use case to not include PAM support for sudo (while having other packages use it as well). If this is a the case, maybe there should be a configuration option which defaults to include PAM support (when the PAM package exists) which can be explicitly disabled by the developer.
Comment 2 Thomas Petazzoni 2015-12-18 08:24:32 UTC
(In reply to James Knight from comment #1)
Our sudo package is already automatically installing a /etc/pam.d/sudo file, see:

ifeq ($(BR2_PACKAGE_LINUX_PAM),y)
define SUDO_INSTALL_PAM_CONF
        $(INSTALL) -D -m 0644 package/sudo/sudo.pam $(TARGET_DIR)/etc/pam.d/sudo
endef

So I guess the bug reporter expect things to work properly out of the box. James, did you test with the /etc/pam.d/sudo file installed by default by Buildroot?
Comment 3 nroach44 2015-12-18 12:00:06 UTC
Just performed a test using the /etc/pam.d/sudo file from debian.

Using buildroot's sudo file a password is prompted for, but it's always wrong

cat /etc/pam.d/sudo
auth        sufficient   pam_rootok.so
auth        required     pam_wheel.so use_uid
auth        required     pam_env.so
auth        required     pam_unix.so nullok

account     required     pam_unix.so

password    required     pam_unix.so nullok

session     required     pam_limits.so
session     required     pam_env.so
session     required     pam_unix.so
###

Using debian's sudo file a password is not prompted for and simply fails three times:

cat /etc/pam.d/sudo
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive
###

[nroach44@charon ~]$ sudo bash
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts

The following shows in journalctl:

Jan 01 09:01:25 charon sudo[1094]: PAM (sudo) illegal module type: @include
Jan 01 09:01:25 charon sudo[1094]: PAM pam_parse: expecting return value; [...common-auth]
Jan 01 09:01:25 charon sudo[1094]: PAM (sudo) no module name supplied

So it seems like the format is different for whatever reason.
Comment 4 Doug Kehn 2015-12-18 14:03:40 UTC
Created attachment 6256 [details]
sudo.pam LDAP patch
Comment 5 Doug Kehn 2015-12-18 14:10:11 UTC
Sorry, my comments didn't get associated with the patch.

Thomas is correct, the stock Buildroot sudo.pam does not work 'out of the box' with LDAP. I had modified /etc/pam.d/sudo to adhere to desired security policy.

The patch gets /etc/pam.d/sudo working with LDAP for me. Please try and let me know if it solves your issue. I don't mind doing a proper patch if it does.

Regards,
...doug
Comment 6 James Knight 2015-12-18 23:32:30 UTC
(In reply to Thomas Petazzoni from comment #2)
I am using Buildroot's provided /etc/pam.d/sudo file.


(In reply to nroach44 from comment #3)
Interesting.

Just took a gander at Fedora's (22) variant:

cat /etc/pam.d/sudo
#%PAM-1.0
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so
session    include      system-auth

(where system-auth file contains a boat load of more entries)

I guess Debian's PAM format varies from RedHat's PAM variant (although I haven't really looked into it).


(In reply to Doug Kehn from comment #5)
Should Buildroot's sudo.pam work 'out of the box' with LDAP? I'm not against it but just glancing at my own target, I do not have the pam_ldap.so module installed.


(all)
While it might not fit all use cases, I believe the Buildroot-provided /etc/pam.d/sudo file is generic enough for a standard setup; but, given the woes that nroach44 is experiencing, it might be missing something.

@nroach44, in your sudo configuration you mentioned (comment #0) you have the following:

%sudo ALL=(ALL) ALL

I assume you're trying to give the "sudo" group permission (instead of using the wheel group). What happens when you try to alter the following file (see [1]):

auth required pam_wheel.so use_uid group=sudo

I'm also curious if the root user can use sudo in your system (ie. I assume `sudo echo a` is failing for your default user but does it also fail when running under root)?

 [1]: http://www.linux-pam.org/Linux-PAM-html/sag-pam_wheel.html
Comment 7 nroach44 2015-12-19 01:53:11 UTC
When I try to sudo from my user:

Jan 01 09:08:59 charon sudo[1092]: [[0;1;31mnroach44 : 3 incorrect password attempts ; TTY=ttyS0 ; PWD=/root ; USER=root ; COMMAND=/bin/bash[[0m

I can confirm that my password is being typed correctly as I changed it to 'a' and tried again.

Adding myself to wheel does allow me to sudo strangely enough, which is curious as the sudo group works fine when sudo is built without PAM.
Comment 8 Doug Kehn 2015-12-21 14:08:02 UTC
Hi Everyone,

The /etc/pam.d/sudo line:
     auth        required    pam_wheel.so use_uid
requires that the user is a member of the wheel group. When sudo is built without PAM, the PAM databases are not queried so the user does not have be a member of wheel.

Try changing the line to:
     auth        sufficient   pam_wheel.so use_uid
or comment it out to allow non-wheel group users sudo access. The user still has to be listed in sudoers.

Hope this helps,
...doug
Comment 9 Thomas Petazzoni 2016-10-22 21:15:36 UTC
This is just a configuration problem, and not a bug in Buildroot.

The default /etc/sudoers file in Buildroot only contains:

root ALL=(ALL) ALL

And you have decided to enable in addition:

%sudo   ALL=(ALL) ALL

to allow users of the sudo group to be able to execute commands as root using sudo.

However, when you enable PAM, we install the following default /etc/pam.d/sudo:

auth        sufficient   pam_rootok.so
auth        required     pam_wheel.so use_uid
auth        required     pam_env.so
auth        required     pam_unix.so nullok

account     required     pam_unix.so

password    required     pam_unix.so nullok

session     required     pam_limits.so
session     required     pam_env.so
session     required     pam_unix.so

The second line, that uses the pam_wheel.so is the one that restricts switching to the root account to users members of the "wheel" group. If you want to allow members of the sudo group to switch to root, you need to change it to:

auth        required     pam_wheel.so use_uid group=sudo

I've tested, and it just works fine.

But of course, whether you enable sudo for users that are part of the wheel group, or part of the sudo group is only related to *your* customization of /etc/sudoers.

So there's nothing wrong in Buildroot's current setup. If you had uncommented the line in /etc/sudoers that allow users part of the wheel group to use sudo, you wouldn't have seen this problem.

Therefore, I don't consider this as a bug, but simply as a system customization issue.