Also note that if you remove /usr/local/sbin and /usr/local/bin from the default path for root, this is then inconsistent with the default path for regular users (unless you want to remove them there too, which I think would be really unpopular).

/usr/local/sbin:/usr/local/bin is definitely a secure path, because those directories are writable only by root, and

Despite that they're writable by root, what about the human expectation of it? I personally don't know of a sysadmin, myself included, that would consider /usr/local anything a secure path. That could lead to disastrous results down the road if the expectation is that root won't run anything from /usr/local by default

As such, I'm in complete agreement with what @mattdm said in the previous ruling:

For what it's worth, with my former-sysadmin hat on and not my FPL one, I am mildly opposed. I think it's better for the default secure_path to include only system binaries, requiring explicit paths for other situations including /usr/local/sbin. Sites which use such directories heavily can easily change the secure_path value

It is frankly a shock to me that /usr/local anything is in path by default for anything root at all, and is something I will be manually patching out of my systems from here on out.

I propose that /usr/local* is removed from all default configurations where root is a concern, and that any such use of that directory should be an opt-in affair.

I agree with @kkofler here, /usr/local is only writable by root and as an example it is the place for the admin to adjust the installation without creating issues with the package manager. Why is it considered unsecure?

@xenithorb /usr/local is defined by Filesystem Hierarchy Standard (FHS) for more then decade, why is this suddenly a surprise now. I don't think disabling it is a good idea. Removing that /usr/local would only fragment Fedora from the rest of Linux distributions.

As @lupinix, I am also wondering why is this not considered secure?

FESCo Meeting 2017-11-03

#agreed Proposal: Discuss on the mailing list and in ticket, vote at next week's FESCo meeting based on feedback (+1:7, +0:0, -1:0)

Last week we agreed to discuss this on a mailing list or in this ticket, but we haven't had that discussion yet, so I'll kick it off.

I personally am in favor of leaving it up to the sudo maintainer in this case. In my opinion, it is not unexpected that su and sudo would yield different paths, as they are for different use cases and usually also for different users. Thus, making them consistent doesn't strike me as being a necessary goal or even a useful goal. To be clear, I'm not opposed to them being consistent either, but I am of the view that FESCo should not override packager's decisions unless there is a compelling benefit to doing so and I do not see a compelling benefit here.

We will discuss this issue during Friday's FESCo meeting at 16:00UTC in #fedora-meeting on
irc.freenode.net. All interested parties are invited to participate.

CC sudo maintainers: @mildew @kzak @mattdm @tosykora @jvymazal @rsroka

Doews anybody know off the top of their head which package sets the root user's default PATH on a fresh fedora install? i'd like to CC the maintainers on this ticket.

The path settings are done in /etc/profile and that file belongs to pkg setup (at least that is in fedora 25)
Name : setup
Arch : noarch
Epoch : 0
Version : 2.10.4
Release : 1.fc25
Size : 698 k
Repo : @System
From repo : anaconda
Summary : A set of system configuration and setup files
URL : https://fedorahosted.org/setup/
License : Public Domain
Description : The setup package contains a set of important system configuration and
: setup files, such as passwd, group, and profile.

My opinion on the /usr/local/bin and /usr/local/sbin issue that it should remain.Don't break general behaviour. People will ass it manually and be annoyed they have to add it.
I also don't understand why it would be a security risk. If a someone can inject a fake script/bin in /usr/local/sbin, he or she can also do it in /usr/sbin.

Well, software archaeology is wonderful thing :-)

#define _PATH_DEFPATH "/usr/local/bin:/bin:/usr/bin"
-#define _PATH_DEFPATH_ROOT SBINDIR ":/bin:" USRSBINDIR ":/usr/bin"
+#define _PATH_DEFPATH_ROOT "/usr/local/sbin:/usr/local/bin:" SBINDIR ":/bin:" USRSBINDIR ":/usr/bin"

this change is from util-linux v2.11t, year 2002. So, it seems we're fine with /usr/local/* for more than 15 years.

I don't plan to change it. I guess our users assume something like backward compatibility.

Anyway, if you don't like the current default setting then login(1) as well as su(1) allow to override the default by ENV_PATH and ENV_ROOTPATH configuration in /etc/login.defs (or /etc/default/{su,runuser} to keep it su specific). For more details see login(1) and su(1) man pages.

BTW, my /usr/local/* is not empty ;-)

Looked up defaults for secure_path set in /etc/sudoers for other popular distributions.

Debian Strech:

Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Ubuntu Trusty:

Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Arch:

## Uncomment to use a hard-coded PATH instead of the user's to find commands
# Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

openSUSE Tumbleweed:

Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin"

This issue will be discussed during this week's FESCo meeting on Friday at 16:00UTC in #fedora-meeting on irc.freenode.net.

CC setup maintainers: @ovasik @pknirsch @karsten

I'm the current maintainer of setup (karsten and phil no longer maintain it) - however, we have public holiday on Fri and I will not be able to attend the call. I don't have strong opinion about this, though, so I can do whatever is required in setup package based on the FESCO decision. Please let me know through Rawhide bugzilla about the decision. Thanks!

#agreed The setup and sudo package maintainers are free to make the decision about this issue without FESCo (+6, 0, -0)