Re: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits

Re: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits

[kernel test robot]

Hi Mickaël,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b]

url:    https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/exec-Add-a-new-AT_CHECK-flag-to-execveat-2/20241012-024801
base:   8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b
patch link:    https://lore.kernel.org/r/20241011184422.977903-3-mic%40digikod.net
patch subject: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
config: alpha-allnoconfig (https://download.01.org/0day-ci/archive/20241015/202410150702.GVWMEEA4-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241015/202410150702.GVWMEEA4-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410150702.GVWMEEA4-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from include/linux/securebits.h:5,
                    from include/linux/init_task.h:13,
                    from init/init_task.c:2:
>> include/uapi/linux/securebits.h:135:23: warning: "/*" within comment [-Wcomment]
     135 |  *       (e.g. sh /tmp/*.sh).  This makes sense for (semi-restricted) user
         |                        


vim +135 include/uapi/linux/securebits.h

    97	
    98	#define SECBIT_EXEC_RESTRICT_FILE (issecure_mask(SECURE_EXEC_RESTRICT_FILE))
    99	#define SECBIT_EXEC_RESTRICT_FILE_LOCKED \
   100				(issecure_mask(SECURE_EXEC_RESTRICT_FILE_LOCKED))
   101	
   102	/*
   103	 * When SECBIT_EXEC_DENY_INTERACTIVE is set, a process should never interpret
   104	 * interactive user commands (e.g. scripts).  However, if such commands are
   105	 * passed through a file descriptor (e.g. stdin), its content should be
   106	 * interpreted if a call to execveat(2) with the related file descriptor and
   107	 * the AT_CHECK flag succeed.
   108	 *
   109	 * For instance, script interpreters called with a script snippet as argument
   110	 * should always deny such execution if SECBIT_EXEC_DENY_INTERACTIVE is set.
   111	 *
   112	 * This secure bit may be set by user session managers, service managers,
   113	 * container runtimes, sandboxer tools...  Except for test environments, the
   114	 * related SECBIT_EXEC_DENY_INTERACTIVE_LOCKED bit should also be set.
   115	 *
   116	 * See the SECBIT_EXEC_RESTRICT_FILE documentation.
   117	 *
   118	 * Here is the expected behavior for a script interpreter according to
   119	 * combination of any exec securebits:
   120	 *
   121	 * 1. SECURE_EXEC_RESTRICT_FILE=0 SECURE_EXEC_DENY_INTERACTIVE=0 (default)
   122	 *    Always interpret scripts, and allow arbitrary user commands.
   123	 *    => No threat, everyone and everything is trusted, but we can get ahead of
   124	 *       potential issues thanks to the call to execveat with AT_CHECK which
   125	 *       should always be performed but ignored by the script interpreter.
   126	 *       Indeed, this check is still important to enable systems administrators
   127	 *       to verify requests (e.g. with audit) and prepare for migration to a
   128	 *       secure mode.
   129	 *
   130	 * 2. SECURE_EXEC_RESTRICT_FILE=1 SECURE_EXEC_DENY_INTERACTIVE=0
   131	 *    Deny script interpretation if they are not executable, but allow
   132	 *    arbitrary user commands.
   133	 *    => The threat is (potential) malicious scripts run by trusted (and not
   134	 *       fooled) users.  That can protect against unintended script executions
 > 135	 *       (e.g. sh /tmp/*.sh).  This makes sense for (semi-restricted) user
   136	 *       sessions.
   137	 *
   138	 * 3. SECURE_EXEC_RESTRICT_FILE=0 SECURE_EXEC_DENY_INTERACTIVE=1
   139	 *    Always interpret scripts, but deny arbitrary user commands.
   140	 *    => This use case may be useful for secure services (i.e. without
   141	 *       interactive user session) where scripts' integrity is verified (e.g.
   142	 *       with IMA/EVM or dm-verity/IPE) but where access rights might not be
   143	 *       ready yet.  Indeed, arbitrary interactive commands would be much more
   144	 *       difficult to check.
   145	 *
   146	 * 4. SECURE_EXEC_RESTRICT_FILE=1 SECURE_EXEC_DENY_INTERACTIVE=1
   147	 *    Deny script interpretation if they are not executable, and also deny
   148	 *    any arbitrary user commands.
   149	 *    => The threat is malicious scripts run by untrusted users (but trusted
   150	 *       code).  This makes sense for system services that may only execute
   151	 *       trusted scripts.
   152	 */
   153	#define SECURE_EXEC_DENY_INTERACTIVE		10
   154	#define SECURE_EXEC_DENY_INTERACTIVE_LOCKED	11  /* make bit-10 immutable */
   155	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits

[kernel test robot]

Hi Mickaël,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b]

url:    https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/exec-Add-a-new-AT_CHECK-flag-to-execveat-2/20241012-024801
base:   8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b
patch link:    https://lore.kernel.org/r/20241011184422.977903-3-mic%40digikod.net
patch subject: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
config: arm-allnoconfig (https://download.01.org/0day-ci/archive/20241015/202410150756.KOkRl5oz-lkp@intel.com/config)
compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project 70e0a7e7e6a8541bcc46908c592eed561850e416)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241015/202410150756.KOkRl5oz-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410150756.KOkRl5oz-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from init/init_task.c:2:
   In file included from include/linux/init_task.h:9:
   In file included from include/linux/ftrace.h:13:
   In file included from include/linux/kallsyms.h:13:
   In file included from include/linux/mm.h:2213:
   include/linux/vmstat.h:518:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
     518 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
         |                               ~~~~~~~~~~~ ^ ~~~
   In file included from init/init_task.c:2:
   In file included from include/linux/init_task.h:13:
   In file included from include/linux/securebits.h:5:
>> include/uapi/linux/securebits.h:135:23: warning: '/*' within block comment [-Wcomment]
     135 |  *       (e.g. sh /tmp/*.sh).  This makes sense for (semi-restricted) user
         |                       ^
   2 warnings generated.


vim +135 include/uapi/linux/securebits.h

    97	
    98	#define SECBIT_EXEC_RESTRICT_FILE (issecure_mask(SECURE_EXEC_RESTRICT_FILE))
    99	#define SECBIT_EXEC_RESTRICT_FILE_LOCKED \
   100				(issecure_mask(SECURE_EXEC_RESTRICT_FILE_LOCKED))
   101	
   102	/*
   103	 * When SECBIT_EXEC_DENY_INTERACTIVE is set, a process should never interpret
   104	 * interactive user commands (e.g. scripts).  However, if such commands are
   105	 * passed through a file descriptor (e.g. stdin), its content should be
   106	 * interpreted if a call to execveat(2) with the related file descriptor and
   107	 * the AT_CHECK flag succeed.
   108	 *
   109	 * For instance, script interpreters called with a script snippet as argument
   110	 * should always deny such execution if SECBIT_EXEC_DENY_INTERACTIVE is set.
   111	 *
   112	 * This secure bit may be set by user session managers, service managers,
   113	 * container runtimes, sandboxer tools...  Except for test environments, the
   114	 * related SECBIT_EXEC_DENY_INTERACTIVE_LOCKED bit should also be set.
   115	 *
   116	 * See the SECBIT_EXEC_RESTRICT_FILE documentation.
   117	 *
   118	 * Here is the expected behavior for a script interpreter according to
   119	 * combination of any exec securebits:
   120	 *
   121	 * 1. SECURE_EXEC_RESTRICT_FILE=0 SECURE_EXEC_DENY_INTERACTIVE=0 (default)
   122	 *    Always interpret scripts, and allow arbitrary user commands.
   123	 *    => No threat, everyone and everything is trusted, but we can get ahead of
   124	 *       potential issues thanks to the call to execveat with AT_CHECK which
   125	 *       should always be performed but ignored by the script interpreter.
   126	 *       Indeed, this check is still important to enable systems administrators
   127	 *       to verify requests (e.g. with audit) and prepare for migration to a
   128	 *       secure mode.
   129	 *
   130	 * 2. SECURE_EXEC_RESTRICT_FILE=1 SECURE_EXEC_DENY_INTERACTIVE=0
   131	 *    Deny script interpretation if they are not executable, but allow
   132	 *    arbitrary user commands.
   133	 *    => The threat is (potential) malicious scripts run by trusted (and not
   134	 *       fooled) users.  That can protect against unintended script executions
 > 135	 *       (e.g. sh /tmp/*.sh).  This makes sense for (semi-restricted) user
   136	 *       sessions.
   137	 *
   138	 * 3. SECURE_EXEC_RESTRICT_FILE=0 SECURE_EXEC_DENY_INTERACTIVE=1
   139	 *    Always interpret scripts, but deny arbitrary user commands.
   140	 *    => This use case may be useful for secure services (i.e. without
   141	 *       interactive user session) where scripts' integrity is verified (e.g.
   142	 *       with IMA/EVM or dm-verity/IPE) but where access rights might not be
   143	 *       ready yet.  Indeed, arbitrary interactive commands would be much more
   144	 *       difficult to check.
   145	 *
   146	 * 4. SECURE_EXEC_RESTRICT_FILE=1 SECURE_EXEC_DENY_INTERACTIVE=1
   147	 *    Deny script interpretation if they are not executable, and also deny
   148	 *    any arbitrary user commands.
   149	 *    => The threat is malicious scripts run by untrusted users (but trusted
   150	 *       code).  This makes sense for system services that may only execute
   151	 *       trusted scripts.
   152	 */
   153	#define SECURE_EXEC_DENY_INTERACTIVE		10
   154	#define SECURE_EXEC_DENY_INTERACTIVE_LOCKED	11  /* make bit-10 immutable */
   155	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki