From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/sudo: make adding 'sudo' group+rule optional
Date: Wed, 6 Nov 2019 23:36:58 +0100 [thread overview]
Message-ID: <20191106233658.305cd426@windsurf> (raw)
In-Reply-To: <20191105224229.20488-1-stephan@asklandd.dk>
Hello Stephan,
Thanks for your patch!
On Tue, 5 Nov 2019 23:42:29 +0100
Stephan Henningsen <stephan@asklandd.dk> wrote:
> From: Stephan Henningsen <stephan+buildroot@asklandd.dk>
>
> I have concerns about the change that was made to my original patch;
> Instead of having the 'sudo' group and sudoers rule enabled by the user
> manually and thereby giving her concent, a change was made to apply the
> option silently.
>
> While I do understand that making this all default will make the user
> experience a bit smoother, I fear that this won't be the case for
> everyone.
>
> My motivations for making it an option to begin with (and for this
> follow-up patch) are the following:
>
> 1) Not everyone may be interested in the added rule to /etc/sudoers; it
> may even conflict with a custom rule. For example if a custom rule was
> added that does not prompt for user password, then the newly added rule,
> which does prompt for user password, maybe break automated cronjobs that
> rely on sudo for elevated priviledges without a password prompt.
>
> 2) Adding this group and rule is only one of many use-cases of the sudo
> package; some people may prefer adding custom rules that only allow
> certain well-known users (e.g. alice, bob) or certain system groups
> (e.g. wheel, daemon) to become root. These users may have to manually
> revert the changes now done to their /etc/sudoers.
>
> 3) If only a little, this addition adds to the size of the system's
> attack surface, potentially inadvertently allowing users to become root.
>
> 4) Not everyone may be interested in the added non-standard system group
> 'sudo'; they may even have to manually revert the changes now done to
> their /etc/groups to trim it.
>
> 5) We're chaning default behavior of a security-critical package that may
> affect systems that have run in production of years.
>
> Most of this is just speculation, of course. But the fact remains that
> the default behavior of a package that deals with elevating user
> priviledges has been changed, and for no real reason at all. "If it ain't
> broke, don't fix it" certain seems fitting, I think.
We can't provide options for every bit of system configuration. Having
a sudo group, configured by default so that the users in this group can
use sudo, seems like a sensible default. Buildroot has traditionally
had a policy of: let's have sensible/basic defaults for the configuration of
most packages, and leave it up to the user to further customize such defaults.
Here, it is pretty trivial to override the sudoers file with its own
version in a rootfs-overlay, and also trivial to remove the sudo group
from /etc/group in a post-build script if really needed.
So overall, I agree with the change Yann did to simply make the sudo
group and sudoers unconditional.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2019-11-06 22:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 22:42 [Buildroot] [PATCH 1/1] package/sudo: make adding 'sudo' group+rule optional Stephan Henningsen
2019-11-06 22:36 ` Thomas Petazzoni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191106233658.305cd426@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox