New flag `A` to pass env-vars unchanged

[hilbix]

Currently most environment variables are prefixed with SUID_ to disarm unknown possible future environmental bombs like LD_PRELOAD in the past. But it is a PITA to move all necessary variables back, just in case we need them as-is (and the program is secure like statically compiled).

Hence proposal for a new way to handle environment:

• By default, no environment is passed at all, except for the following 4 (most secure):
  • TERM, default PATH, SUIDUID, SUIDGID and SUIDPWD
• Flag to pass the environment rewritten, as today (Flag B like Before)
• Flag to pass the environment mostly unchanged (Flag A like Attention)
  • This still renames PATH and LD_* variables (and in future possibly others).
• Flag to pass the environment completely unchanged (Flag AB)
• Note that this still must be mixed with S to allow ShellShock

Alternatives:

• /usr/bin/env:-i:--: is similar to the proposed above new default.
  • But to type this it might be error prone to type compared to "leave away all flags".
• We can create wrappers, which preporcess the environment to our liking.
  • So above can be emulated today by re-inventing the wheel at your side.
  • Which is good, but not comfortable.

Rationale:

• Being as secure as possible is the default for suid.
  • Passing no environment at all is the most secure option
  • Changing that behavior might break existing programs. Which is bad.
  • So better do it now as suid is not widely used and do not wait for later where such changes get momentum.
  • However the way the environment is passed today should be completely secure in almost all cases. (Except flaws in scripts.) So there is no immediate pressure.
• When switching to "No environment" we need a "pass env again" flag.
  • But the goal is to support most common usage, too, and this is to pass mostly all environment unchanged, but disarm only those variables known to be problematic.
  • Hence we need a 2nd Flag. This allows us to have 4 variants: nothing, like-now, mostly-harmless, live-dangerous
  • As Flags must be alphabetically sorted, we need two characters near each other. As else it might be difficult to spot things, which is error prone.
  • As passing environment probably is used a lot, this should come handy. Hence at the end or at the start of the flags.
  • YZ or XY do not sound as good as AB. Hence proposing AB

[hilbix]

To be more specific:

• Default (no flags) is to NOT pass Env. This removes the complete environment like in env -i --
• A then re-enables passing Env with SUID_ prefixed
• B then passing "mostly-harmless" environment variables unchanged (no prefix). Dangerous variables are still prefixed.
• AB then passes environment completely unchanged, including extremely dangerous variables like LD_PRELOAD
• Add S to pass even ShellShock variables

Additionally AB should NOT work by default, such that if you add this, the command is disabled until explicitly enabled.

Hence we need to invent some way to silence this warning. The idea here is:

• If some dangerous setting is detected, the command is automatically disabled.
• It then can be enabled again by adding some Magic
• If the line changes, the Magic changes, too
• Same happens if suid is enhanced and detects some more "bad" practice. Then the Magic changes, again.

I am currently undecided how to archive that. Here is a plan:

• All detected dangers get some ID
• These IDs plus the configuration line are hashed into some value (Not necessarily a cryptographically secure hash)
• This value must be present somewhere

Two things are important:

• This must not introduce complicated code into suid
• This must be easy to understand and to maintain for users

Either it becomes part of the line (like being added to the flags field)
or it must be added to the next line as a comment (looks like #HASH#)

I like the latter approach, as this does not need to change the line (which might be error prone) and can easily be scripted (inserting a line is not a big problem). Calculating the hash code also can be implemented in linereader on the fly (if needed).

The "next line" approach also can support #HASH#HASH#HASH# to enable variants of a line. This is good for testing and development, when you often change the flags (or other aspects) and do not want to be disturbed by the line become disabled.

Alternatively it can be "previous line", such that we just can remember the previous line in some buffer.

This even leaves opportunities like passing that line into the environment, such that the called script is able to verify that it is legit.

• This passing can be added using flag C (like Context), which then passes some suid internal possibly security related context to the script (which might not be suitable to scripts which are not aware of this nature)
  • Flag C then requires the authenticating line, too.

[hilbix]

We cannot use C as it is already taken by arg0 given to cmd is first arg given to 'suid'

Free letters are

• E which I do want to use already, even that it matches "environment"
• H perhaps something like Help
• JKLM a block I want to keep for future
• Q is just too nice for things like Quiet
• V is just too nice for things like Verbose
• XYZ is a block I want to keep unused currently

I vote for V, as this puts something "verbosely" into environment. You can also read this as "verify".

[hilbix]

List of possibly exploitable environment variables:

• IFS - may affect read in scripts
• TERM - may affect the used terminal emulator
• HOSTALIASES
• RESOLV_ADD_TRIM_DOMAINS
• RESOLV_MULTI
• RESOLV_OVERRIDE_TRIM_DOMAINS
• RESOLV_REORDER
• RESOLV_SERV_ORDER
• RESOLV_SPOOF_CHECK

List of known to be dangerous environment variables:

• PATH - can disturb the search path
• PS1 - can make shells execute things on prompt
• LANGUAGE - see next
• LC_* - may change the outcome of a script
  • LC_ALL - may affect outcome of a program and irritate scripts
• POSIXLY_CORRECT - may make argument processing unpredictable

List of highly dangerous environment variables:

• LD_* - also see below
  • LD_DEBUG_PATH - may override system files?
• GLIBC_TUNABLES - CVE-2023-4911

I cannot find information about this in the glibc-doc, instead see LFS: http://www.scratchbox.org/documentation/general/tutorials/glibcenv.html

Lists from glibc (is there a way to automate this?):

• MALLOC_CHECK_
• GCONV_PATH
• HOSTALIASES
• LD_AOUT_LIBRARY_PATH
• LD_AOUT_PRELOAD
• LD_DEBUG_OUTPUT
• LD_LIBRARY_PATH
• LD_ORIGIN_PATH
• LD_PRELOAD
• LD_PROFILE
• LOCALDOMAIN
• LOCPATH
• MALLOC_TRACE
• NLSPATH
• RESOLV_HOST_CONF
• RES_OPTIONS
• TMPDIR
• TZDIR

Note that suid never will detect presence of files like /etc/suid-debug, because it always must behave 100% predicatble and such settings not only affects the debuged part but everything.

To enable debugging you must alter /etc/suid.conf or /etc/suid.conf.*/*.conf files.

Notes:

• getconf -a lists some variables
• GLIBC_TUNABLES is not amongst them
• LD_* is not amongst them

[hilbix]

Due to CVE-2023-4911 I changed my mind:

Apparently it is far too dangerous to pass unknown variables to a script. Hence the new plan is twofold:

• Passing the environment with SUID_ prefixed should be safe.
  • So keep that by default
  • If you do not like then environment, use env -i
  • Perhaps introduce some prefix :noenv: for this
  • Or some option
• Often calling something through suid is clumsy due to SUID_ prefix
  • So there must be some option to allow to pass the environment
• Switching back into unprivileged context
  • Then the user can only attack the own commands or other unprivileged commands
  • There should be some easy to use option to do that
• There should be also a way to pass certain variables into root context
  • Example is SSH_AUTH_SOCK

So this probably better:

• Only use flag A (keep free B and V)
• If A and B are missing, pass everything as SUID_ as now
• A for unprivileged context
  • A like "All"
  • Passes all environment variables unchanged
• A for privileged context (even if called by root):
  • A like "Allowed"
  • Passes only some explicitly "allowed" environment variables
  • All others are passed with SUID_ prefix

Notes:

• As options must be alphabetically ordered A always is the first option
  • Hence it can be prominently be seen.
• The list of privileged environment variables must not be in the same line
  • This list might become very long, so it may make things unreadable or hard to grok
• Hence the "next line approach" seems to be viable
  • However I still do not like that as this might clash with commented out commands

Hence the updated idea:

• NAME:PW:UID:GID:OPTIONS:DIR:COMMAND is how a command looks
  • Options starts with A
  • UID and GID are privileged
  • No :suid:, :root: or :toor: etc. present
• #NAME ENV1 ENV2 ENV3 then declares the passed environment variables

Rationale:

• #NAME protects against artifacts showing up at the wrong location
  • Automated scripts which might cat things together, so we need some guard here
• Then ENV variables are space separated
  • Which makes it easy to concatenate them (like with vim)
• Being able to read them (no #hash#) is better than some complicated authentication process

For Authentication, suid should pass additional environment variables:

• SUIDCMD should carry NAME
• SUIDENV is the space separated list of environment variables (from the next line)
  • This should be passed even without A option
• SUIDOPT the OPTIONS
• SUIDDIR the directory as given
  • This allows to pass some chroot marker like /./
  • Do not mix with SUIDPWD which passes the "realpath" of the directory before changing into SUIDDIR
  • Note that SUID_PWD may carry the logical PWD from before which may differ from "realpath"

But those should go into another issue ..