shebang: restrict python interactive prompt/interpreter

This patch defines a new, minor LSM named "shebang", that restricts python such that scripts are allowed to execute, while the interactive prompt/interpreter is not available. When used in conjunction with an IMA appraise execute policy requiring files signatures, only signed python scripts would be allowed to execute. (A separate method for identifying "imported" code would need to be defined in order to verify their file signatures.)

security/shebang/shebang_python.c new file +25 -0

+#define MAX_INODES 6 
+static char *pathnames;
+static int pathnames_len;
+static unsigned long inode_list[MAX_INODES];
+static int total;
+
+/*
+ * Get the inodes associated with the list of pathnames, as specified
+ * on CONFIG_SECURITY_SHEBANG_PATHNAME.
+ */
+static void init_inode_list(void)
+{
+	char *tmp_pathnames = pathnames;
+	char *p;
+	struct path path;
+	int i;
+	int ret;
+
+	total = 0;
+	while ((p = strsep(&tmp_pathnames, " ,")) != NULL) {
+		if ((*p == '\0') || (*p == ' ') || (*p == ','))
+			continue;
+
+		if (total > MAX_INODES - 1) {
+			pr_info("too many interpreters\n");

security/shebang/shebang_python.c new file +9 -0

+}
+
+/**
+ * shebang_bprm_check - prevent python interactive prompt/interpreter
+ * @bprm: contains the linux_binprm structure
+ *
+ * Restrict python such that scripts are allowed to execute, while the
+ * interactive prompt/interpreter is not available.
+ */

security/shebang/shebang_python.c new file +12 -0

+
+	while (i < total) {
+		if (inode_list[i++] != inode->i_ino)
+			continue;
+
+		pr_info("prevent executing %s (ino=%lu)\n",
+			bprm->interp, inode->i_ino);
+		return -EPERM;
+	}
+	return 0;
+}
+

Quoted 7 lines · Mimi Zohar

This patch defines a new, minor LSM named "shebang", that restricts python such that scripts are allowed to execute, while the interactive prompt/interpreter is not available. When used in conjunction with an IMA appraise execute policy requiring files signatures, only signed python scripts would be allowed to execute. (A separate method for identifying "imported" code would need to be defined in order to verify their file signatures.)

Below case is blocked by IMA?

   $ cp -p /usr/bin/python2 /tmp
   $ /tmp/python2

Below case is also blocked by IMA?

   $ echo '#!/usr/bin/python2 -' > /tmp/run-python
   $ chmod +x /tmp/run-python
   $ /tmp/run-python

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Quoted 4 lines

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Just tested this and you are correct, this allows you to bypass the protection.

I was able to fix this bypass by including /lib64/ld-linux-x86-64.so.2 in the list of interpreters.

Quoted 1 line

Quoted 1 line

print "hello"

Quoted 1 line

Quoted 1 line

Quoted 10 lines · Matt Brown

Quoted 4 lines

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Just tested this and you are correct, this allows you to bypass the protection.

I was able to fix this bypass by including /lib64/ld-linux-x86-64.so.2 in the list of interpreters.

And there is also PYTHONINSPECT environment variable. ;-)

# echo '#!/usr/bin/python2' > run-python
# chmod 755 run-python
# ./run-python
# PYTHONINSPECT=yes ./run-python

Quoted 1 line

Quoted 1 line

Quoted 1 line

print "hello"

hello

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 12 lines · Tetsuo Handa

Quoted 10 lines · Matt Brown

Quoted 4 lines

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Just tested this and you are correct, this allows you to bypass the protection.

I was able to fix this bypass by including /lib64/ld-linux-x86-64.so.2 in the list of interpreters.

Quoted 9 lines

And there is also PYTHONINSPECT environment variable. ;-)

# echo '#!/usr/bin/python2' > run-python
# chmod 755 run-python
# ./run-python
# PYTHONINSPECT=yes ./run-python

Quoted 1 line

Quoted 1 line

Quoted 1 line

print "hello"

hello

Quoted 1 line

Quoted 1 line

Quoted 1 line

While this bypass works against this LSM alone, when combined with Trusted Path Execution this is prevented for non-root/untrusted user. This is why I feel like this is such a great feature to combine with TPE as I said here:

http://www.openwall.com/lists/kernel-hardening/2017/06/09/13

Results from my test:

$ PYTHONINSPECT=yes ./run-python

-bash: ./run-python: /usr/bin/python2: bad interpreter: Operation not permitted

and in the dmesg log:
TPE: Denied exec of /home/test/run-python Reason: file in non-root-owned directory

Quoted 1 line

Quoted 1 line

Quoted 35 lines · Matt Brown

Quoted 12 lines · Tetsuo Handa

Quoted 10 lines · Matt Brown

Quoted 4 lines

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Just tested this and you are correct, this allows you to bypass the protection.

I was able to fix this bypass by including /lib64/ld-linux-x86-64.so.2 in the list of interpreters.

Quoted 9 lines

And there is also PYTHONINSPECT environment variable. ;-)

# echo '#!/usr/bin/python2' > run-python
# chmod 755 run-python
# ./run-python
# PYTHONINSPECT=yes ./run-python

Quoted 1 line

Quoted 1 line

Quoted 1 line

print "hello"

hello

Quoted 1 line

Quoted 1 line

Quoted 1 line

While this bypass works against this LSM alone, when combined with Trusted Path Execution this is prevented for non-root/untrusted user. This is why I feel like this is such a great feature to combine with TPE as I said here:

http://www.openwall.com/lists/kernel-hardening/2017/06/09/13

Results from my test:

$ PYTHONINSPECT=yes ./run-python

Quoted 6 lines

-bash: ./run-python: /usr/bin/python2: bad interpreter: Operation not permitted

and in the dmesg log:
TPE: Denied exec of /home/test/run-python Reason: file in non-root-owned directory

What if you just use any existing python script on the system?

jason at meriadoc ~ $ PYTHONINSPECT=yes /usr/bin/emerge
emerge: command-line interface to the Portage system Usage:

   emerge [ options ] [ action ] [ ebuild | tbz2 | file | @set | atom ] [ ... ]
   emerge [ options ] [ action ] < @system | @world >
   emerge < --sync | --metadata | --info >
   emerge --resume [ --pretend | --ask | --skipfirst ]
   emerge --help
Options: -[abBcCdDefgGhjkKlnNoOpPqrsStuvVw]
          [ --color < y | n >            ] [ --columns    ]
          [ --complete-graph             ] [ --deep       ]
          [ --jobs JOBS ] [ --keep-going ] [ --load-average LOAD            ]
          [ --newrepo   ] [ --newuse     ] [ --noconfmem  ] [ --nospinner   ]
          [ --oneshot   ] [ --onlydeps   ] [ --quiet-build [ y | n ]        ]
          [ --reinstall changed-use      ] [ --with-bdeps < y | n >         ]
Actions:  [ --depclean | --list-sets | --search | --sync | --version        ]

For more help consult the man page.
Traceback (most recent call last):
File "/usr/lib/python-exec/python3.4/emerge", line 79, in <module>
sys.exit(retval)
SystemExit: 1

Quoted 1 line

Quoted 1 line

Quoted 1 line

-- Jason

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

Quoted 62 lines · Jason Zaman

Quoted 35 lines · Matt Brown

Quoted 12 lines · Tetsuo Handa

Quoted 10 lines · Matt Brown

Quoted 4 lines

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Just tested this and you are correct, this allows you to bypass the protection.

I was able to fix this bypass by including /lib64/ld-linux-x86-64.so.2 in the list of interpreters.

Quoted 9 lines

And there is also PYTHONINSPECT environment variable. ;-)

# echo '#!/usr/bin/python2' > run-python
# chmod 755 run-python
# ./run-python
# PYTHONINSPECT=yes ./run-python

Quoted 1 line

Quoted 1 line

Quoted 1 line

print "hello"

hello

Quoted 1 line

Quoted 1 line

Quoted 1 line

While this bypass works against this LSM alone, when combined with Trusted Path Execution this is prevented for non-root/untrusted user. This is why I feel like this is such a great feature to combine with TPE as I said here:

http://www.openwall.com/lists/kernel-hardening/2017/06/09/13

Results from my test:

$ PYTHONINSPECT=yes ./run-python

Quoted 6 lines

-bash: ./run-python: /usr/bin/python2: bad interpreter: Operation not permitted

and in the dmesg log:
TPE: Denied exec of /home/test/run-python Reason: file in non-root-owned directory

What if you just use any existing python script on the system?

jason at meriadoc ~ $ PYTHONINSPECT=yes /usr/bin/emerge
emerge: command-line interface to the Portage system Usage:

   emerge [ options ] [ action ] [ ebuild | tbz2 | file | @set | atom ] [ ... ]
   emerge [ options ] [ action ] < @system | @world >
   emerge < --sync | --metadata | --info >
   emerge --resume [ --pretend | --ask | --skipfirst ]
   emerge --help
Options: -[abBcCdDefgGhjkKlnNoOpPqrsStuvVw]
          [ --color < y | n >            ] [ --columns    ]
          [ --complete-graph             ] [ --deep       ]
          [ --jobs JOBS ] [ --keep-going ] [ --load-average LOAD            ]
          [ --newrepo   ] [ --newuse     ] [ --noconfmem  ] [ --nospinner   ]
          [ --oneshot   ] [ --onlydeps   ] [ --quiet-build [ y | n ]        ]
          [ --reinstall changed-use      ] [ --with-bdeps < y | n >         ]
Actions:  [ --depclean | --list-sets | --search | --sync | --version        ]

Quoted 9 lines

For more help consult the man page.
Traceback (most recent call last):
File "/usr/lib/python-exec/python3.4/emerge", line 79, in <module>
sys.exit(retval)
SystemExit: 1

Quoted 1 line

Quoted 1 line

Quoted 1 line

-- Jason

crap you're right. This does work.

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

Quoted 6 lines · Matt Brown

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

As part of shebang, it likely makes sense to whitelist (rather than blacklist) the env of the restricted interpreters. Though this is starting to get complex. :P

Quoted 11 lines · Kees Cook

Quoted 6 lines · Matt Brown

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

As part of shebang, it likely makes sense to whitelist (rather than blacklist) the env of the restricted interpreters. Though this is starting to get complex. :P

Blacklisting environment variables is dangerous. I think that administrators can afford whitelisting environment variable names. I think that implementing whitelist of environment variable names as an independent LSM module would be fine.

While it is true that things starts getting complex if we check environment variables, shebang will already become complex if it starts worrying about updating inode number list in order to close the race window between doing creat()+write()+close()+chmod()+rename() by the package manager and teaching the kernel the new inode number determined by creat(). We will need an interface for allowing the package manager to teach the kernel the new inode number and modification of the package manager, for the kernel side is doing inode number based blacklisting while user side can execute it before rename(). --
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 18 lines · Tetsuo Handa

Quoted 11 lines · Kees Cook

Quoted 6 lines · Matt Brown

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

As part of shebang, it likely makes sense to whitelist (rather than blacklist) the env of the restricted interpreters. Though this is starting to get complex. :P

Blacklisting environment variables is dangerous. I think that administrators can afford whitelisting environment variable names. I think that implementing whitelist of environment variable names as an independent LSM module would be fine.

Quoted 8 lines

While it is true that things starts getting complex if we check environment variables, shebang will already become complex if it starts worrying about updating inode number list in order to close the race window between doing creat()+write()+close()+chmod()+rename() by the package manager and teaching the kernel the new inode number determined by creat(). We will need an interface for allowing the package manager to teach the kernel the new inode number and modification of the package manager, for the kernel side is doing inode number based blacklisting while user side can execute it before rename().

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Using filesystem xattr seems like a good idea for this kind of exceptions and instead of a hardcoded interpreter path. Something like "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to configure a security policy for some binaries. This could also be protected by IMA/EVM, if needed.

This kind of xattr should be writable by the owner of the file. The TPE LSM [1] could then take these xattr into account according to the TPE policy.

The "security.tpe.environment" could also be set on a script file to be part of the union with the interpreter's environment whitelist. This may be needed to be able to use environment variables as configuration in a script.

In the future, a "security.tpe.memory" could contain a set of flags as PaX uses for mprotect-like exceptions (user.pax.flags).

Userland daemons such as paxctld or paxrat could be used (with some tweaks) to keep a consistent TPE policy over time.

Mickaël

[1] https://lkml.kernel.org/r/[email protected]

Quoted 6 lines · Mickaël Salaün

Using filesystem xattr seems like a good idea for this kind of exceptions and instead of a hardcoded interpreter path. Something like "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to configure a security policy for some binaries. This could also be protected by IMA/EVM, if needed.

Checking for the existence of an xattr without caching is relatively slow.  I'm not sure that we would want to go this route.

Quoted 9 lines · Mimi Zohar

Quoted 6 lines · Mickaël Salaün

Using filesystem xattr seems like a good idea for this kind of exceptions and instead of a hardcoded interpreter path. Something like "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to configure a security policy for some binaries. This could also be protected by IMA/EVM, if needed.

Quoted 2 lines

Checking for the existence of an xattr without caching is relatively slow. I'm not sure that we would want to go this route.

For identifying interpreters, xattrs would be too slow (without caching results), but once identified, using xattrs as you suggested, for specifying how interpreters can be invoked and limiting environment variables, is a good idea. Perhaps the two xattrs could be combined?

Quoted 9 lines · Mimi Zohar

Quoted 6 lines · Mickaël Salaün

Using filesystem xattr seems like a good idea for this kind of exceptions and instead of a hardcoded interpreter path. Something like "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to configure a security policy for some binaries. This could also be protected by IMA/EVM, if needed.

Quoted 2 lines

Checking for the existence of an xattr without caching is relatively slow.  I'm not sure that we would want to go this route.

For identifying interpreters, xattrs would be too slow (without caching results), but once identified, using xattrs as you suggested, for specifying how interpreters can be invoked and limiting environment variables, is a good idea.  Perhaps the two xattrs could be combined?

Quoted 10 lines · On Mon, 12 Jun 2017 10:27:24 -0400 Mimi Zohar <[email protected]> wrote:

Quoted 9 lines · Mimi Zohar

Quoted 6 lines · Mickaël Salaün

Using filesystem xattr seems like a good idea for this kind of exceptions and instead of a hardcoded interpreter path. Something like "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to configure a security policy for some binaries. This could also be protected by IMA/EVM, if needed.

Quoted 8 lines

Quoted 2 lines

Checking for the existence of an xattr without caching is relatively slow. I'm not sure that we would want to go this route.

For identifying interpreters, xattrs would be too slow (without caching results), but once identified, using xattrs as you suggested, for specifying how interpreters can be invoked and limiting environment variables, is a good idea. Perhaps the two xattrs could be combined?

It's not just #! you need to cover. If I can run ld.so for my arch format then ld.so will helpfully let me load any ELF binary I like and run it.

Alan

Quoted 19 lines · Mickaël Salaün

Quoted 18 lines · Tetsuo Handa

Quoted 11 lines · Kees Cook

Quoted 6 lines · Matt Brown

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

As part of shebang, it likely makes sense to whitelist (rather than blacklist) the env of the restricted interpreters. Though this is starting to get complex. :P

Blacklisting environment variables is dangerous. I think that administrators can afford whitelisting environment variable names. I think that implementing whitelist of environment variable names as an independent LSM module would be fine.

Quoted 8 lines

Quoted 8 lines

While it is true that things starts getting complex if we check environment variables, shebang will already become complex if it starts worrying about updating inode number list in order to close the race window between doing creat()+write()+close()+chmod()+rename() by the package manager and teaching the kernel the new inode number determined by creat(). We will need an interface for allowing the package manager to teach the kernel the new inode number and modification of the package manager, for the kernel side is doing inode number based blacklisting while user side can execute it before rename().

I don't think we're trying to protect against executing the interpreter prior to the rename. Rename, itself, would trigger associating the interpreter name with an inode number.

Quoted 6 lines

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines

Using filesystem xattr seems like a good idea for this kind of exceptions and instead of a hardcoded interpreter path. Something like "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to configure a security policy for some binaries. This could also be protected by IMA/EVM, if needed.

Checking for the existence of an xattr without caching is relatively slow. I'm not sure that we would want to go this route.

Quoted 3 lines

This kind of xattr should be writable by the owner of the file. The TPE LSM [1] could then take these xattr into account according to the TPE policy.

Security xattrs are only writable by root.

Quoted 44 lines · Mimi Zohar

Quoted 17 lines · Mickaël Salaün

Quoted 16 lines · Tetsuo Handa

Quoted 10 lines · Kees Cook

Quoted 6 lines · Matt Brown

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

As part of shebang, it likely makes sense to whitelist (rather than blacklist) the env of the restricted interpreters. Though this is starting to get complex. :P

Blacklisting environment variables is dangerous. I think that administrators can afford whitelisting environment variable names. I think that implementing whitelist of environment variable names as an independent LSM module would be fine.

Quoted 8 lines

Quoted 8 lines

While it is true that things starts getting complex if we check environment variables, shebang will already become complex if it starts worrying about updating inode number list in order to close the race window between doing creat()+write()+close()+chmod()+rename() by the package manager and teaching the kernel the new inode number determined by creat(). We will need an interface for allowing the package manager to teach the kernel the new inode number and modification of the package manager, for the kernel side is doing inode number based blacklisting while user side can execute it before rename().

I don't think we're trying to protect against executing the interpreter prior to the rename. Rename, itself, would trigger associating the interpreter name with an inode number.

Quoted 11 lines

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Using filesystem xattr seems like a good idea for this kind of exceptions and instead of a hardcoded interpreter path. Something like "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to configure a security policy for some binaries. This could also be protected by IMA/EVM, if needed.

Checking for the existence of an xattr without caching is relatively slow. I'm not sure that we would want to go this route.

Quoted 4 lines

Quoted 3 lines

This kind of xattr should be writable by the owner of the file. The TPE LSM [1] could then take these xattr into account according to the TPE policy.

Security xattrs are only writable by root.

This is currently the case but an exception for this kind of LSM could be allowed, or another dedicated prefix could be used.

Quoted 8 lines · Kees Cook

Quoted 6 lines · Matt Brown

what does everyone thing about a envp_blacklist option that is a list of environmental variables that will be stripped from exec calls. This can be done in the LSM hook bprm_check_security.

Is there any reason on a hardened system why you would need the PYTHONINSPECT environmental variable?

Quoted 3 lines

As part of shebang, it likely makes sense to whitelist (rather than blacklist) the env of the restricted interpreters. Though this is starting to get complex. :P

Blacklisting environment variables is dangerous. I think that administrators can afford whitelisting environment variable names. I think that implementing whitelist of environment variable names as an independent LSM module would be fine.

While it is true that things starts getting complex if we check environment variables, shebang will already become complex if it starts worrying about updating inode number list in order to close the race window between doing creat()+write()+close()+chmod()+rename() by the package manager and teaching the kernel the new inode number determined by creat(). We will need an interface for allowing the package manager to teach the kernel the new inode number and modification of the package manager, for the kernel side is doing inode number based blacklisting while user side can execute it before rename().

Quoted 4 lines

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Just tested this and you are correct, this allows you to bypass the protection.

I was able to fix this bypass by including /lib64/ld-linux-x86-64.so.2 in the list of interpreters.

Quoted 7 lines · Mimi Zohar

This patch defines a new, minor LSM named "shebang", that restricts python such that scripts are allowed to execute, while the interactive prompt/interpreter is not available. When used in conjunction with an IMA appraise execute policy requiring files signatures, only signed python scripts would be allowed to execute. (A separate method for identifying "imported" code would need to be defined in order to verify their file signatures.)

Below case is blocked by IMA?

   $ cp -p /usr/bin/python2 /tmp
   $ /tmp/python2

Below case is also blocked by IMA?

   $ echo '#!/usr/bin/python2 -' > /tmp/run-python
   $ chmod +x /tmp/run-python
   $ /tmp/run-python

What about execution via ld-linux ?

   $ /lib64/ld-linux-x86-64.so.2 /usr/bin/python2

Quoted 29 lines

security/shebang/shebang_python.c new file +29 -0

+#define MAX_INODES 6 
+static char *pathnames;
+static int pathnames_len;
+static unsigned long inode_list[MAX_INODES];
+static int total;
+
+/*
+ * Get the inodes associated with the list of pathnames, as specified
+ * on CONFIG_SECURITY_SHEBANG_PATHNAME.
+ */
+static void init_inode_list(void)
+{
+	char *tmp_pathnames = pathnames;
+	char *p;
+	struct path path;
+	int i;
+	int ret;
+
+	total = 0;
+	while ((p = strsep(&tmp_pathnames, " ,")) != NULL) {
+		if ((*p == '\0') || (*p == ' ') || (*p == ','))
+			continue;
+
+		if (total > MAX_INODES - 1) {
+			pr_info("too many interpreters\n");
+			break;
+		}
+
+		ret = kern_path(p, LOOKUP_FOLLOW, &path);

security/shebang/shebang_python.c line 58

Quoted 6 lines

security/shebang/shebang_python.c new file +6 -0

+		if (!ret) {
+			struct inode *inode = d_backing_inode(path.dentry);
+
+			inode_list[total] = inode->i_ino;
+			pr_info("pathname:%s i_ino: %lu\n",
+				p, inode_list[total]);

Leaking reference to "struct path".

Quoted 4 lines

security/shebang/shebang_python.c new file +4 -0

+			initialized = 1;
+			total++;
+		}
+	}

security/shebang/shebang_python.c line 68

Quoted 6 lines

security/shebang/shebang_python.c new file +6 -0

+
+	/* cleanup in case we need to lookup the inodes again. */
+	tmp_pathnames = pathnames;
+	for (i = 0; i < pathnames_len; i++)
+		if (tmp_pathnames[i] == '\0')
+			tmp_pathnames[i] = ' ';

Why need to restore?

Quoted 13 lines

security/shebang/shebang_python.c new file +13 -0

+}
+
+/**
+ * shebang_bprm_check - prevent python interactive prompt/interpreter
+ * @bprm: contains the linux_binprm structure
+ *
+ * Restrict python such that scripts are allowed to execute, while the
+ * interactive prompt/interpreter is not available.
+ */
+static int shebang_bprm_check(struct linux_binprm *bprm)
+{
+	struct inode *inode = file_inode(bprm->file);
+	int i = 0;

security/shebang/shebang_python.c line 87

Quoted 6 lines

security/shebang/shebang_python.c new file +6 -0

+
+	if (bprm->interp != bprm->filename)	/* allow scripts */
+		return 0;
+
+	if (!initialized)
+		init_inode_list();

init_inode_list() can be called concurrently.

Quoted 13 lines

security/shebang/shebang_python.c new file +12 -0

+
+	while (i < total) {
+		if (inode_list[i++] != inode->i_ino)
+			continue;
+
+		pr_info("prevent executing %s (ino=%lu)\n",
+			bprm->interp, inode->i_ino);
+		return -EPERM;
+	}
+	return 0;
+}
+

security/shebang/shebang_python.c line 109

Quoted 10 lines

security/shebang/shebang_python.c new file +10 -0

+static struct security_hook_list shebang_hooks[] = {
+	LSM_HOOK_INIT(bprm_check_security, shebang_bprm_check)
+};
+
+static int __init init_shebang(void)
+{
+	pathnames = kstrdup(CONFIG_SECURITY_SHEBANG_PATHNAME, GFP_KERNEL);
+	if (!pathnames)
+		return -ENOMEM;
+	pathnames_len = strlen(pathnames);

Why need to kstrdup()?

  static char pathnames[] = CONFIG_SECURITY_SHEBANG_PATHNAME;
  static int pathnames_len = sizeof(pathnames) - 1;

will be fine.

security/shebang/shebang_python.c line 117

Quoted 8 lines

security/shebang/shebang_python.c new file +8 -0

+
+	security_add_hooks(shebang_hooks, ARRAY_SIZE(shebang_hooks), "shebang");
+	pr_info("initialized\n");
+	return 0;
+}
+
+late_initcall(init_shebang);
+MODULE_LICENSE("GPL");

Nice example for loading as a LKM-based LSM. ;-)

Quoted 9 lines

security/shebang/shebang_python.c line 58

Quoted 7 lines

security/shebang/shebang_python.c new file +7 -0

+		ret = kern_path(p, LOOKUP_FOLLOW, &path);
+		if (!ret) {
+			struct inode *inode = d_backing_inode(path.dentry);
+
+			inode_list[total] = inode->i_ino;
+			pr_info("pathname:%s i_ino: %lu\n",
+				p, inode_list[total]);

Leaking reference to "struct path".

kern_path() is calling "getname_kernel(name)", but that is later freed. I'm not seeing it. What are you referring to?