-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/21/2011 12:12 PM, Stephen Smalley wrote:
> On Thu, 2011-04-21 at 15:30 +0100, David Howells wrote:
>> Currently, the caller must be able to open the script interpreter and/or the
>> binary loader that an executable wants to make use of, even if the executable
>> will be transitioned to a different context that can make use of that
>> interpreter or loader when the caller's context does not permit it.
>>
>> Override credentials in open_exec() and kernel_read() with the currently
>> constructed new credentials so that if the executable file or its interpreter
>> specifies a transition to a different security context (DAC or MAC), then the
>> caller only has to provide access to the file to be executed, and not to the
>> interpreter (e.g. perl) or binary loader (e.g. ld.so) for the executable or
>> interpreter.
>>
>> This means that if the caller does not have access to a script interpreter or
>> binary loader, it can still use scripts and executables that transition to a
>> security context that do.
>>
>> Tetsuo Handa pointed out that TOMOYO had a problem because the loader image
>> (such as ld-config.so) was checked with the wrong credentials (open_exec() is
>> using the caller's credentials rather than credentials-to-be of the exec'd
>> process.
>>
>> I note that this also applies to scripts and their interpreters. A script may
>> end up getting run in a context that allows access to its interpreter, but
>> that's no good if the caller of execve() doesn't permit the script interpreter
>> to be opened.
>>
>> Here's a set of patches to deal with this. The last patch is the main
>> ingredient.
>>
>>
>> I have a couple of comments/questions on the above:
>>
>> (1) Consider a SUID binary. If the loader for that binary is executable by
>> the uid to which the binary changes its uid on execution, but not by the
>> uid of the caller, should execution succeed?
>>
>> For example, if, as root, I do this:
>>
>> cp -v /bin/ls /tmp/ls
>> perl -p -i -e s/ld-linux/ld-linuQ/ /tmp/ls
>> cp -v /lib64/ld-linux-x86-64.so.2 /lib64/ld-linuQ-x86-64.so.2
>> chmod -v 0700 /lib64/ld-linuQ-x86-64.so.2
>>
>> then as myself do this:
>>
>> /tmp/ls
>>
>> this currently fails with permission denied; but with patch (5) above
>> applied, it works. Obviously, this is a contrived example, but it also
>> may applies to script interpreters if an LSM provides a security ID
>> transition.
>>
>> (2) Conversely, if the loader is not executable by the uid to which an SUID
>> executable switches, should that execution succeed?
>>
>> So if I alter the ownership and permissions on the above binaries:
>>
>> chown -v dhowells /lib64/ld-linuQ-x86-64.so.2
>> chown -v bin /tmp/ls
>> chmod u+s /tmp/ls
>>
>> then as myself do:
>>
>> /tmp/ls
>>
>> this works with patches removed and gives permission denied with it
>> applied.
>>
>> (3) The SUID/SGID changes from patch 5 that I've noted in comments (1) and (2)
>> should, I think, have no impact on the execution environment because:
>>
>> (*) loaders and interpreters are normally accessible to everyone in
>> their DAC permissions (UID, GID, umask), and
>>
>> (*) recursing through prepare_binprm() multiple times only takes
>> account of the SUID/SGID settings of the final level (which means
>> that whilst you can have a SUID/SGID interpreter, you can't have a
>> SUID/SGID script).
>>
>> An exception to this are binfmt_misc cases that have
>> MISC_FMT_CREDENTIALS flagged - in those the credentials remain
>> unchanged for the iteration, even if the next executable is
>> SUID/SGID.
>>
>> (4) SELinux's testsuite needs the following additional rules:
>>
>> [policy/test_ptrace.te]
>> allow test_ptrace_traced_t bin_t:file { execute read open };
>>
>> [policy/test_file.te]
>> allow fileop_t fileop_exec_t:file { execute read open };
>>
>> to permit the ptrace test to access its script interpreter (perl) and the
>> SIGIO file test's wait_io program to access its own executable.
>
> This is an interesting change, but as it does change user-visible
> behavior, does it need to be subject to some /proc/sys/kernel toggle so
> that users can retain the existing behavior? And does at least the SUID
> behavior change require discussion on lkml?
>
Could we use this change to prevent the execution of scripts in the
homedir?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2wW5kACgkQrlYvE4MpobMHZACgwrHyHF9hzs0lAhftf9D0Gy/W
oKUAoMXxECkganLDs2RLsauufNCz9R6i
=82tP
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
