LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
/*
|
|
|
|
|
* security/tomoyo/tomoyo.c
|
|
|
|
|
*
|
|
|
|
|
* LSM hooks for TOMOYO Linux.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2005-2009 NTT DATA CORPORATION
|
|
|
|
|
*
|
2009-04-08 13:31:28 +00:00
|
|
|
* Version: 2.2.0 2009/04/01
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/security.h>
|
|
|
|
|
#include "common.h"
|
|
|
|
|
#include "tomoyo.h"
|
|
|
|
|
#include "realpath.h"
|
|
|
|
|
|
KEYS: Add a keyctl to install a process's session keyring on its parent [try #6]
Add a keyctl to install a process's session keyring onto its parent. This
replaces the parent's session keyring. Because the COW credential code does
not permit one process to change another process's credentials directly, the
change is deferred until userspace next starts executing again. Normally this
will be after a wait*() syscall.
To support this, three new security hooks have been provided:
cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
the blank security creds and key_session_to_parent() - which asks the LSM if
the process may replace its parent's session keyring.
The replacement may only happen if the process has the same ownership details
as its parent, and the process has LINK permission on the session keyring, and
the session keyring is owned by the process, and the LSM permits it.
Note that this requires alteration to each architecture's notify_resume path.
This has been done for all arches barring blackfin, m68k* and xtensa, all of
which need assembly alteration to support TIF_NOTIFY_RESUME. This allows the
replacement to be performed at the point the parent process resumes userspace
execution.
This allows the userspace AFS pioctl emulation to fully emulate newpag() and
the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
alter the parent process's PAG membership. However, since kAFS doesn't use
PAGs per se, but rather dumps the keys into the session keyring, the session
keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
the newpag flag.
This can be tested with the following program:
#include <stdio.h>
#include <stdlib.h>
#include <keyutils.h>
#define KEYCTL_SESSION_TO_PARENT 18
#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
int main(int argc, char **argv)
{
key_serial_t keyring, key;
long ret;
keyring = keyctl_join_session_keyring(argv[1]);
OSERROR(keyring, "keyctl_join_session_keyring");
key = add_key("user", "a", "b", 1, keyring);
OSERROR(key, "add_key");
ret = keyctl(KEYCTL_SESSION_TO_PARENT);
OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");
return 0;
}
Compiled and linked with -lkeyutils, you should see something like:
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
355907932 --alswrv 4043 -1 \_ keyring: _uid.4043
[dhowells@andromeda ~]$ /tmp/newpag
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
1055658746 --alswrv 4043 4043 \_ user: a
[dhowells@andromeda ~]$ /tmp/newpag hello
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: hello
340417692 --alswrv 4043 4043 \_ user: a
Where the test program creates a new session keyring, sticks a user key named
'a' into it and then installs it on its parent.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
2009-09-02 08:14:21 +00:00
|
|
|
static int tomoyo_cred_alloc_blank(struct cred *new, gfp_t gfp)
|
|
|
|
|
{
|
|
|
|
|
new->security = NULL;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
static int tomoyo_cred_prepare(struct cred *new, const struct cred *old,
|
|
|
|
|
gfp_t gfp)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Since "struct tomoyo_domain_info *" is a sharable pointer,
|
|
|
|
|
* we don't need to duplicate.
|
|
|
|
|
*/
|
|
|
|
|
new->security = old->security;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
KEYS: Add a keyctl to install a process's session keyring on its parent [try #6]
Add a keyctl to install a process's session keyring onto its parent. This
replaces the parent's session keyring. Because the COW credential code does
not permit one process to change another process's credentials directly, the
change is deferred until userspace next starts executing again. Normally this
will be after a wait*() syscall.
To support this, three new security hooks have been provided:
cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
the blank security creds and key_session_to_parent() - which asks the LSM if
the process may replace its parent's session keyring.
The replacement may only happen if the process has the same ownership details
as its parent, and the process has LINK permission on the session keyring, and
the session keyring is owned by the process, and the LSM permits it.
Note that this requires alteration to each architecture's notify_resume path.
This has been done for all arches barring blackfin, m68k* and xtensa, all of
which need assembly alteration to support TIF_NOTIFY_RESUME. This allows the
replacement to be performed at the point the parent process resumes userspace
execution.
This allows the userspace AFS pioctl emulation to fully emulate newpag() and
the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
alter the parent process's PAG membership. However, since kAFS doesn't use
PAGs per se, but rather dumps the keys into the session keyring, the session
keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
the newpag flag.
This can be tested with the following program:
#include <stdio.h>
#include <stdlib.h>
#include <keyutils.h>
#define KEYCTL_SESSION_TO_PARENT 18
#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
int main(int argc, char **argv)
{
key_serial_t keyring, key;
long ret;
keyring = keyctl_join_session_keyring(argv[1]);
OSERROR(keyring, "keyctl_join_session_keyring");
key = add_key("user", "a", "b", 1, keyring);
OSERROR(key, "add_key");
ret = keyctl(KEYCTL_SESSION_TO_PARENT);
OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");
return 0;
}
Compiled and linked with -lkeyutils, you should see something like:
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
355907932 --alswrv 4043 -1 \_ keyring: _uid.4043
[dhowells@andromeda ~]$ /tmp/newpag
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
1055658746 --alswrv 4043 4043 \_ user: a
[dhowells@andromeda ~]$ /tmp/newpag hello
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: hello
340417692 --alswrv 4043 4043 \_ user: a
Where the test program creates a new session keyring, sticks a user key named
'a' into it and then installs it on its parent.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
2009-09-02 08:14:21 +00:00
|
|
|
static void tomoyo_cred_transfer(struct cred *new, const struct cred *old)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Since "struct tomoyo_domain_info *" is a sharable pointer,
|
|
|
|
|
* we don't need to duplicate.
|
|
|
|
|
*/
|
|
|
|
|
new->security = old->security;
|
|
|
|
|
}
|
|
|
|
|
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
static int tomoyo_bprm_set_creds(struct linux_binprm *bprm)
|
|
|
|
|
{
|
2009-05-26 03:15:53 +00:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
rc = cap_bprm_set_creds(bprm);
|
|
|
|
|
if (rc)
|
|
|
|
|
return rc;
|
|
|
|
|
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
/*
|
|
|
|
|
* Do only if this function is called for the first time of an execve
|
|
|
|
|
* operation.
|
|
|
|
|
*/
|
|
|
|
|
if (bprm->cred_prepared)
|
|
|
|
|
return 0;
|
|
|
|
|
/*
|
|
|
|
|
* Load policy if /sbin/tomoyo-init exists and /sbin/init is requested
|
|
|
|
|
* for the first time.
|
|
|
|
|
*/
|
|
|
|
|
if (!tomoyo_policy_loaded)
|
|
|
|
|
tomoyo_load_policy(bprm->filename);
|
|
|
|
|
/*
|
|
|
|
|
* Tell tomoyo_bprm_check_security() is called for the first time of an
|
|
|
|
|
* execve operation.
|
|
|
|
|
*/
|
|
|
|
|
bprm->cred->security = NULL;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_bprm_check_security(struct linux_binprm *bprm)
|
|
|
|
|
{
|
|
|
|
|
struct tomoyo_domain_info *domain = bprm->cred->security;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Execute permission is checked against pathname passed to do_execve()
|
|
|
|
|
* using current domain.
|
|
|
|
|
*/
|
2009-12-08 00:34:43 +00:00
|
|
|
if (!domain) {
|
|
|
|
|
/*
|
|
|
|
|
* We will need to protect whole execve() operation when GC
|
|
|
|
|
* starts kfree()ing "struct tomoyo_domain_info" because
|
|
|
|
|
* bprm->cred->security points to "struct tomoyo_domain_info"
|
|
|
|
|
* but "struct tomoyo_domain_info" does not have a refcounter.
|
|
|
|
|
*/
|
|
|
|
|
const int idx = tomoyo_read_lock();
|
|
|
|
|
const int err = tomoyo_find_next_domain(bprm);
|
|
|
|
|
tomoyo_read_unlock(idx);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
/*
|
|
|
|
|
* Read permission is checked against interpreters using next domain.
|
|
|
|
|
* '1' is the result of open_to_namei_flags(O_RDONLY).
|
|
|
|
|
*/
|
|
|
|
|
return tomoyo_check_open_permission(domain, &bprm->file->f_path, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_truncate(struct path *path, loff_t length,
|
|
|
|
|
unsigned int time_attrs)
|
|
|
|
|
{
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_TRUNCATE_ACL,
|
|
|
|
|
path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_unlink(struct path *parent, struct dentry *dentry)
|
|
|
|
|
{
|
|
|
|
|
struct path path = { parent->mnt, dentry };
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_UNLINK_ACL,
|
|
|
|
|
&path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_mkdir(struct path *parent, struct dentry *dentry,
|
|
|
|
|
int mode)
|
|
|
|
|
{
|
|
|
|
|
struct path path = { parent->mnt, dentry };
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_MKDIR_ACL,
|
|
|
|
|
&path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_rmdir(struct path *parent, struct dentry *dentry)
|
|
|
|
|
{
|
|
|
|
|
struct path path = { parent->mnt, dentry };
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_RMDIR_ACL,
|
|
|
|
|
&path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_symlink(struct path *parent, struct dentry *dentry,
|
|
|
|
|
const char *old_name)
|
|
|
|
|
{
|
|
|
|
|
struct path path = { parent->mnt, dentry };
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_SYMLINK_ACL,
|
|
|
|
|
&path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_mknod(struct path *parent, struct dentry *dentry,
|
|
|
|
|
int mode, unsigned int dev)
|
|
|
|
|
{
|
|
|
|
|
struct path path = { parent->mnt, dentry };
|
|
|
|
|
int type = TOMOYO_TYPE_CREATE_ACL;
|
|
|
|
|
|
|
|
|
|
switch (mode & S_IFMT) {
|
|
|
|
|
case S_IFCHR:
|
|
|
|
|
type = TOMOYO_TYPE_MKCHAR_ACL;
|
|
|
|
|
break;
|
|
|
|
|
case S_IFBLK:
|
|
|
|
|
type = TOMOYO_TYPE_MKBLOCK_ACL;
|
|
|
|
|
break;
|
|
|
|
|
case S_IFIFO:
|
|
|
|
|
type = TOMOYO_TYPE_MKFIFO_ACL;
|
|
|
|
|
break;
|
|
|
|
|
case S_IFSOCK:
|
|
|
|
|
type = TOMOYO_TYPE_MKSOCK_ACL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
type, &path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_link(struct dentry *old_dentry, struct path *new_dir,
|
|
|
|
|
struct dentry *new_dentry)
|
|
|
|
|
{
|
|
|
|
|
struct path path1 = { new_dir->mnt, old_dentry };
|
|
|
|
|
struct path path2 = { new_dir->mnt, new_dentry };
|
|
|
|
|
return tomoyo_check_2path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_LINK_ACL,
|
|
|
|
|
&path1, &path2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_rename(struct path *old_parent,
|
|
|
|
|
struct dentry *old_dentry,
|
|
|
|
|
struct path *new_parent,
|
|
|
|
|
struct dentry *new_dentry)
|
|
|
|
|
{
|
|
|
|
|
struct path path1 = { old_parent->mnt, old_dentry };
|
|
|
|
|
struct path path2 = { new_parent->mnt, new_dentry };
|
|
|
|
|
return tomoyo_check_2path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_RENAME_ACL,
|
|
|
|
|
&path1, &path2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_file_fcntl(struct file *file, unsigned int cmd,
|
|
|
|
|
unsigned long arg)
|
|
|
|
|
{
|
|
|
|
|
if (cmd == F_SETFL && ((arg ^ file->f_flags) & O_APPEND))
|
|
|
|
|
return tomoyo_check_rewrite_permission(tomoyo_domain(), file);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_dentry_open(struct file *f, const struct cred *cred)
|
|
|
|
|
{
|
|
|
|
|
int flags = f->f_flags;
|
|
|
|
|
|
|
|
|
|
if ((flags + 1) & O_ACCMODE)
|
|
|
|
|
flags++;
|
|
|
|
|
flags |= f->f_flags & (O_APPEND | O_TRUNC);
|
|
|
|
|
/* Don't check read permission here if called from do_execve(). */
|
|
|
|
|
if (current->in_execve)
|
|
|
|
|
return 0;
|
|
|
|
|
return tomoyo_check_open_permission(tomoyo_domain(), &f->f_path, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 12:09:48 +00:00
|
|
|
static int tomoyo_file_ioctl(struct file *file, unsigned int cmd,
|
|
|
|
|
unsigned long arg)
|
|
|
|
|
{
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(), TOMOYO_TYPE_IOCTL_ACL,
|
|
|
|
|
&file->f_path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_chmod(struct dentry *dentry, struct vfsmount *mnt,
|
|
|
|
|
mode_t mode)
|
|
|
|
|
{
|
|
|
|
|
struct path path = { mnt, dentry };
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(), TOMOYO_TYPE_CHMOD_ACL,
|
|
|
|
|
&path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_chown(struct path *path, uid_t uid, gid_t gid)
|
|
|
|
|
{
|
|
|
|
|
int error = 0;
|
|
|
|
|
if (uid != (uid_t) -1)
|
|
|
|
|
error = tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_CHOWN_ACL, path);
|
|
|
|
|
if (!error && gid != (gid_t) -1)
|
|
|
|
|
error = tomoyo_check_1path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_CHGRP_ACL, path);
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_path_chroot(struct path *path)
|
|
|
|
|
{
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(), TOMOYO_TYPE_CHROOT_ACL,
|
|
|
|
|
path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_sb_mount(char *dev_name, struct path *path,
|
|
|
|
|
char *type, unsigned long flags, void *data)
|
|
|
|
|
{
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(), TOMOYO_TYPE_MOUNT_ACL,
|
|
|
|
|
path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_sb_umount(struct vfsmount *mnt, int flags)
|
|
|
|
|
{
|
|
|
|
|
struct path path = { mnt, mnt->mnt_root };
|
|
|
|
|
return tomoyo_check_1path_perm(tomoyo_domain(), TOMOYO_TYPE_UMOUNT_ACL,
|
|
|
|
|
&path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tomoyo_sb_pivotroot(struct path *old_path, struct path *new_path)
|
|
|
|
|
{
|
|
|
|
|
return tomoyo_check_2path_perm(tomoyo_domain(),
|
|
|
|
|
TOMOYO_TYPE_PIVOT_ROOT_ACL,
|
|
|
|
|
new_path, old_path);
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-08 03:37:39 +00:00
|
|
|
/*
|
|
|
|
|
* tomoyo_security_ops is a "struct security_operations" which is used for
|
|
|
|
|
* registering TOMOYO.
|
|
|
|
|
*/
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
static struct security_operations tomoyo_security_ops = {
|
|
|
|
|
.name = "tomoyo",
|
KEYS: Add a keyctl to install a process's session keyring on its parent [try #6]
Add a keyctl to install a process's session keyring onto its parent. This
replaces the parent's session keyring. Because the COW credential code does
not permit one process to change another process's credentials directly, the
change is deferred until userspace next starts executing again. Normally this
will be after a wait*() syscall.
To support this, three new security hooks have been provided:
cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
the blank security creds and key_session_to_parent() - which asks the LSM if
the process may replace its parent's session keyring.
The replacement may only happen if the process has the same ownership details
as its parent, and the process has LINK permission on the session keyring, and
the session keyring is owned by the process, and the LSM permits it.
Note that this requires alteration to each architecture's notify_resume path.
This has been done for all arches barring blackfin, m68k* and xtensa, all of
which need assembly alteration to support TIF_NOTIFY_RESUME. This allows the
replacement to be performed at the point the parent process resumes userspace
execution.
This allows the userspace AFS pioctl emulation to fully emulate newpag() and
the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
alter the parent process's PAG membership. However, since kAFS doesn't use
PAGs per se, but rather dumps the keys into the session keyring, the session
keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
the newpag flag.
This can be tested with the following program:
#include <stdio.h>
#include <stdlib.h>
#include <keyutils.h>
#define KEYCTL_SESSION_TO_PARENT 18
#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
int main(int argc, char **argv)
{
key_serial_t keyring, key;
long ret;
keyring = keyctl_join_session_keyring(argv[1]);
OSERROR(keyring, "keyctl_join_session_keyring");
key = add_key("user", "a", "b", 1, keyring);
OSERROR(key, "add_key");
ret = keyctl(KEYCTL_SESSION_TO_PARENT);
OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");
return 0;
}
Compiled and linked with -lkeyutils, you should see something like:
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
355907932 --alswrv 4043 -1 \_ keyring: _uid.4043
[dhowells@andromeda ~]$ /tmp/newpag
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
1055658746 --alswrv 4043 4043 \_ user: a
[dhowells@andromeda ~]$ /tmp/newpag hello
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: hello
340417692 --alswrv 4043 4043 \_ user: a
Where the test program creates a new session keyring, sticks a user key named
'a' into it and then installs it on its parent.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
2009-09-02 08:14:21 +00:00
|
|
|
.cred_alloc_blank = tomoyo_cred_alloc_blank,
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
.cred_prepare = tomoyo_cred_prepare,
|
KEYS: Add a keyctl to install a process's session keyring on its parent [try #6]
Add a keyctl to install a process's session keyring onto its parent. This
replaces the parent's session keyring. Because the COW credential code does
not permit one process to change another process's credentials directly, the
change is deferred until userspace next starts executing again. Normally this
will be after a wait*() syscall.
To support this, three new security hooks have been provided:
cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
the blank security creds and key_session_to_parent() - which asks the LSM if
the process may replace its parent's session keyring.
The replacement may only happen if the process has the same ownership details
as its parent, and the process has LINK permission on the session keyring, and
the session keyring is owned by the process, and the LSM permits it.
Note that this requires alteration to each architecture's notify_resume path.
This has been done for all arches barring blackfin, m68k* and xtensa, all of
which need assembly alteration to support TIF_NOTIFY_RESUME. This allows the
replacement to be performed at the point the parent process resumes userspace
execution.
This allows the userspace AFS pioctl emulation to fully emulate newpag() and
the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
alter the parent process's PAG membership. However, since kAFS doesn't use
PAGs per se, but rather dumps the keys into the session keyring, the session
keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
the newpag flag.
This can be tested with the following program:
#include <stdio.h>
#include <stdlib.h>
#include <keyutils.h>
#define KEYCTL_SESSION_TO_PARENT 18
#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
int main(int argc, char **argv)
{
key_serial_t keyring, key;
long ret;
keyring = keyctl_join_session_keyring(argv[1]);
OSERROR(keyring, "keyctl_join_session_keyring");
key = add_key("user", "a", "b", 1, keyring);
OSERROR(key, "add_key");
ret = keyctl(KEYCTL_SESSION_TO_PARENT);
OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");
return 0;
}
Compiled and linked with -lkeyutils, you should see something like:
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
355907932 --alswrv 4043 -1 \_ keyring: _uid.4043
[dhowells@andromeda ~]$ /tmp/newpag
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
1055658746 --alswrv 4043 4043 \_ user: a
[dhowells@andromeda ~]$ /tmp/newpag hello
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: hello
340417692 --alswrv 4043 4043 \_ user: a
Where the test program creates a new session keyring, sticks a user key named
'a' into it and then installs it on its parent.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
2009-09-02 08:14:21 +00:00
|
|
|
.cred_transfer = tomoyo_cred_transfer,
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
.bprm_set_creds = tomoyo_bprm_set_creds,
|
|
|
|
|
.bprm_check_security = tomoyo_bprm_check_security,
|
|
|
|
|
.file_fcntl = tomoyo_file_fcntl,
|
|
|
|
|
.dentry_open = tomoyo_dentry_open,
|
|
|
|
|
.path_truncate = tomoyo_path_truncate,
|
|
|
|
|
.path_unlink = tomoyo_path_unlink,
|
|
|
|
|
.path_mkdir = tomoyo_path_mkdir,
|
|
|
|
|
.path_rmdir = tomoyo_path_rmdir,
|
|
|
|
|
.path_symlink = tomoyo_path_symlink,
|
|
|
|
|
.path_mknod = tomoyo_path_mknod,
|
|
|
|
|
.path_link = tomoyo_path_link,
|
|
|
|
|
.path_rename = tomoyo_path_rename,
|
2009-12-02 12:09:48 +00:00
|
|
|
.file_ioctl = tomoyo_file_ioctl,
|
|
|
|
|
.path_chmod = tomoyo_path_chmod,
|
|
|
|
|
.path_chown = tomoyo_path_chown,
|
|
|
|
|
.path_chroot = tomoyo_path_chroot,
|
|
|
|
|
.sb_mount = tomoyo_sb_mount,
|
|
|
|
|
.sb_umount = tomoyo_sb_umount,
|
|
|
|
|
.sb_pivotroot = tomoyo_sb_pivotroot,
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
};
|
|
|
|
|
|
2009-12-08 00:34:43 +00:00
|
|
|
/* Lock for GC. */
|
|
|
|
|
struct srcu_struct tomoyo_ss;
|
|
|
|
|
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
static int __init tomoyo_init(void)
|
|
|
|
|
{
|
|
|
|
|
struct cred *cred = (struct cred *) current_cred();
|
|
|
|
|
|
|
|
|
|
if (!security_module_enable(&tomoyo_security_ops))
|
|
|
|
|
return 0;
|
|
|
|
|
/* register ourselves with the security framework */
|
2009-12-08 00:34:43 +00:00
|
|
|
if (register_security(&tomoyo_security_ops) ||
|
|
|
|
|
init_srcu_struct(&tomoyo_ss))
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
panic("Failure registering TOMOYO Linux");
|
|
|
|
|
printk(KERN_INFO "TOMOYO Linux initialized\n");
|
|
|
|
|
cred->security = &tomoyo_kernel_domain;
|
2009-02-21 11:40:50 +00:00
|
|
|
tomoyo_realpath_init();
|
LSM adapter functions.
DAC's permissions and TOMOYO's permissions are not one-to-one mapping.
Regarding DAC, there are "read", "write", "execute" permissions.
Regarding TOMOYO, there are "allow_read", "allow_write", "allow_read/write",
"allow_execute", "allow_create", "allow_unlink", "allow_mkdir", "allow_rmdir",
"allow_mkfifo", "allow_mksock", "allow_mkblock", "allow_mkchar",
"allow_truncate", "allow_symlink", "allow_rewrite", "allow_link",
"allow_rename" permissions.
+----------------------------------+----------------------------------+
| requested operation | required TOMOYO's permission |
+----------------------------------+----------------------------------+
| sys_open(O_RDONLY) | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_WRONLY) | allow_write |
+----------------------------------+----------------------------------+
| sys_open(O_RDWR) | allow_read/write |
+----------------------------------+----------------------------------+
| open_exec() from do_execve() | allow_execute |
+----------------------------------+----------------------------------+
| open_exec() from !do_execve() | allow_read |
+----------------------------------+----------------------------------+
| sys_read() | (none) |
+----------------------------------+----------------------------------+
| sys_write() | (none) |
+----------------------------------+----------------------------------+
| sys_mmap() | (none) |
+----------------------------------+----------------------------------+
| sys_uselib() | allow_read |
+----------------------------------+----------------------------------+
| sys_open(O_CREAT) | allow_create |
+----------------------------------+----------------------------------+
| sys_open(O_TRUNC) | allow_truncate |
+----------------------------------+----------------------------------+
| sys_truncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_ftruncate() | allow_truncate |
+----------------------------------+----------------------------------+
| sys_open() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| setfl() without O_APPEND | allow_rewrite |
+----------------------------------+----------------------------------+
| sys_sysctl() for writing | allow_write |
+----------------------------------+----------------------------------+
| sys_sysctl() for reading | allow_read |
+----------------------------------+----------------------------------+
| sys_unlink() | allow_unlink |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFREG) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(0) | allow_create |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFIFO) | allow_mkfifo |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFSOCK) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_bind(AF_UNIX) | allow_mksock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFBLK) | allow_mkblock |
+----------------------------------+----------------------------------+
| sys_mknod(S_IFCHR) | allow_mkchar |
+----------------------------------+----------------------------------+
| sys_symlink() | allow_symlink |
+----------------------------------+----------------------------------+
| sys_mkdir() | allow_mkdir |
+----------------------------------+----------------------------------+
| sys_rmdir() | allow_rmdir |
+----------------------------------+----------------------------------+
| sys_link() | allow_link |
+----------------------------------+----------------------------------+
| sys_rename() | allow_rename |
+----------------------------------+----------------------------------+
TOMOYO requires "allow_execute" permission of a pathname passed to do_execve()
but does not require "allow_read" permission of that pathname.
Let's consider 3 patterns (statically linked, dynamically linked,
shell script). This description is to some degree simplified.
$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
$ cat hello.sh
#! /bin/sh
echo "Hello"
$ gcc -static -o hello-static hello.c
$ gcc -o hello-dynamic hello.c
$ chmod 755 hello.sh
Case 1 -- Executing hello-static from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-static").
(2) The kernel checks "allow_execute hello-static" from "bash" domain.
(3) The kernel calculates "bash hello-static" as the domain to transit to.
(4) The kernel overwrites the child process by "hello-static".
(5) The child process transits to "bash hello-static" domain.
(6) The "hello-static" starts and finishes.
Case 2 -- Executing hello-dynamic from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello-dynamic").
(2) The kernel checks "allow_execute hello-dynamic" from "bash" domain.
(3) The kernel calculates "bash hello-dynamic" as the domain to transit to.
(4) The kernel checks "allow_read ld-linux.so" from "bash hello-dynamic"
domain. I think permission to access ld-linux.so should be charged
hello-dynamic program, for "hello-dynamic needs ld-linux.so" is not
a fault of bash program.
(5) The kernel overwrites the child process by "hello-dynamic".
(6) The child process transits to "bash hello-dynamic" domain.
(7) The "hello-dynamic" starts and finishes.
Case 3 -- Executing hello.sh from bash.
(1) The bash process calls fork() and the child process requests
do_execve("hello.sh").
(2) The kernel checks "allow_execute hello.sh" from "bash" domain.
(3) The kernel calculates "bash hello.sh" as the domain to transit to.
(4) The kernel checks "allow_read /bin/sh" from "bash hello.sh" domain.
I think permission to access /bin/sh should be charged hello.sh program,
for "hello.sh needs /bin/sh" is not a fault of bash program.
(5) The kernel overwrites the child process by "/bin/sh".
(6) The child process transits to "bash hello.sh" domain.
(7) The "/bin/sh" requests open("hello.sh").
(8) The kernel checks "allow_read hello.sh" from "bash hello.sh" domain.
(9) The "/bin/sh" starts and finishes.
Whether a file is interpreted as a program or not depends on an application.
The kernel cannot know whether the file is interpreted as a program or not.
Thus, TOMOYO treats "hello-static" "hello-dynamic" "ld-linux.so" "hello.sh"
"/bin/sh" equally as merely files; no distinction between executable and
non-executable. Therefore, TOMOYO doesn't check DAC's execute permission.
TOMOYO checks "allow_read" permission instead.
Calling do_execve() is a bold gesture that an old program's instance (i.e.
current process) is ready to be overwritten by a new program and is ready to
transfer control to the new program. To split purview of programs, TOMOYO
requires "allow_execute" permission of the new program against the old
program's instance and performs domain transition. If do_execve() succeeds,
the old program is no longer responsible against the consequence of the new
program's behavior. Only the new program is responsible for all consequences.
But TOMOYO doesn't require "allow_read" permission of the new program.
If TOMOYO requires "allow_read" permission of the new program, TOMOYO will
allow an attacker (who hijacked the old program's instance) to open the new
program and steal data from the new program. Requiring "allow_read" permission
will widen purview of the old program.
Not requiring "allow_read" permission of the new program against the old
program's instance is my design for reducing purview of the old program.
To be able to know whether the current process is in do_execve() or not,
I want to add in_execve flag to "task_struct".
Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Signed-off-by: James Morris <jmorris@namei.org>
2009-02-05 08:18:16 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
security_initcall(tomoyo_init);
|
