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>
This file controls domain creation/deletion/transition.
Every process belongs to a domain in TOMOYO Linux.
Domain transition occurs when execve(2) is called
and the domain is expressed as 'process invocation history',
such as '<kernel> /sbin/init /etc/init.d/rc'.
Domain information is stored in current->cred->security field.
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>
This file controls file related operations of TOMOYO Linux.
tomoyo/tomoyo.c calls the following six functions in this file.
Each function handles the following access types.
* tomoyo_check_file_perm
sysctl()'s "read" and "write".
* tomoyo_check_exec_perm
"execute".
* tomoyo_check_open_permission
open(2) for "read" and "write".
* tomoyo_check_1path_perm
"create", "unlink", "mkdir", "rmdir", "mkfifo",
"mksock", "mkblock", "mkchar", "truncate" and "symlink".
* tomoyo_check_2path_perm
"rename" and "unlink".
* tomoyo_check_rewrite_permission
"rewrite".
("rewrite" are operations which may lose already recorded data of a file,
i.e. open(!O_APPEND) || open(O_TRUNC) || truncate() || ftruncate())
The functions which actually checks ACLs are the following three functions.
Each function handles the following access types.
ACL directive is expressed by "allow_<access type>".
* tomoyo_check_file_acl
Open() operation and execve() operation.
("read", "write", "read/write" and "execute")
* tomoyo_check_single_write_acl
Directory modification operations with 1 pathname.
("create", "unlink", "mkdir", "rmdir", "mkfifo", "mksock",
"mkblock", "mkchar", "truncate", "symlink" and "rewrite")
* tomoyo_check_double_write_acl
Directory modification operations with 2 pathname.
("link" and "rename")
Also, this file contains handlers of some utility directives
for file related operations.
* "allow_read": specifies globally (for all domains) readable files.
* "path_group": specifies pathname macro.
* "deny_rewrite": restricts rewrite operation.
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>
This file contains common functions (e.g. policy I/O, pattern matching).
-------------------- About pattern matching --------------------
Since TOMOYO Linux is a name based access control, TOMOYO Linux seriously
considers "safe" string representation.
TOMOYO Linux's string manipulation functions make reviewers feel crazy,
but there are reasons why TOMOYO Linux needs its own string manipulation
functions.
----- Part 1 : preconditions -----
People definitely want to use wild card.
To support pattern matching, we have to support wild card characters.
In a typical Linux system, filenames are likely consists of only alphabets,
numbers, and some characters (e.g. + - ~ . / ).
But theoretically, the Linux kernel accepts all characters but NUL character
(which is used as a terminator of a string).
Some Linux systems can have filenames which contain * ? ** etc.
Therefore, we have to somehow modify string so that we can distinguish
wild card characters and normal characters.
It might be possible for some application's configuration files to restrict
acceptable characters.
It is impossible for kernel to restrict acceptable characters.
We can't accept approaches which will cause troubles for applications.
----- Part 2 : commonly used approaches -----
Text formatted strings separated by space character (0x20) and new line
character (0x0A) is more preferable for users over array of NUL-terminated
string.
Thus, people use text formatted configuration files separated by space
character and new line.
We sometimes need to handle non-printable characters.
Thus, people use \ character (0x5C) as escape character and represent
non-printable characters using octal or hexadecimal format.
At this point, we remind (at least) 3 approaches.
(1) Shell glob style expression
(2) POSIX regular expression (UNIX style regular expression)
(3) Maverick wild card expression
On the surface, (1) and (2) sound good choices. But they have a big pitfall.
All meta-characters in (1) and (2) are legal characters for representing
a pathname, and users easily write incorrect expression. What is worse, users
unlikely notice incorrect expressions because characters used for regular
pathnames unlikely contain meta-characters. This incorrect use of
meta-characters in pathname representation reveals vulnerability
(e.g. unexpected results) only when irregular pathname is specified.
The authors of TOMOYO Linux think that approaches which adds some character
for interpreting meta-characters as normal characters (i.e. (1) and (2)) are
not suitable for security use.
Therefore, the authors of TOMOYO Linux propose (3).
----- Part 3: consideration points -----
We need to solve encoding problem.
A single character can be represented in several ways using encodings.
For Japanese language, there are "ShiftJIS", "ISO-2022-JP", "EUC-JP",
"UTF-8" and more.
Some languages (e.g. Japanese language) supports multi-byte characters
(where a single character is represented using several bytes).
Some multi-byte characters may match the escape character.
For Japanese language, some characters in "ShiftJIS" encoding match
\ character, and bothering Web's CGI developers.
It is important that the kernel string is not bothered by encoding problem.
Linus said, "I really would expect that kernel strings don't have
an encoding. They're just C strings: a NUL-terminated stream of bytes."
http://lkml.org/lkml/2007/11/6/142
Yes. The kernel strings are just C strings.
We are talking about how to store and carry "kernel strings" safely.
If we store "kernel string" into policy file as-is, the "kernel string" will
be interpreted differently depending on application's encoding settings.
One application may interpret "kernel string" as "UTF-8",
another application may interpret "kernel string" as "ShiftJIS".
Therefore, we propose to represent strings using ASCII encoding.
In this way, we are no longer bothered by encoding problems.
We need to avoid information loss caused by display.
It is difficult to input and display non-printable characters, but we have to
be able to handle such characters because the kernel string is a C string.
If we use only ASCII printable characters (from 0x21 to 0x7E) and space
character (0x20) and new line character (0x0A), it is easy to input from
keyboard and display on all terminals which is running Linux.
Therefore, we propose to represent strings using only characters which value
is one of "from 0x21 to 0x7E", "0x20", "0x0A".
We need to consider ease of splitting strings from a line.
If we use an approach which uses "\ " for representing a space character
within a string, we have to count the string from the beginning to check
whether this space character is accompanied with \ character or not.
As a result, we cannot monotonically split a line using space character.
If we use an approach which uses "\040" for representing a space character
within a string, we can monotonically split a line using space character.
If we use an approach which uses NUL character as a delimiter, we cannot
use string manipulation functions for splitting strings from a line.
Therefore, we propose that we represent space character as "\040".
We need to avoid wrong designations (incorrect use of special characters).
Not all users can understand and utilize POSIX's regular expressions
correctly and perfectly.
If a character acts as a wild card by default, the user will get unexpected
result if that user didn't know the meaning of that character.
Therefore, we propose that all characters but \ character act as
a normal character and let the user add \ character to make a character
act as a wild card.
In this way, users needn't to know all wild card characters beforehand.
They can learn when they encountered an unseen wild card character
for their first time.
----- Part 4: supported wild card expressions -----
At this point, we have wild card expressions listed below.
+-----------+--------------------------------------------------------------+
| Wild card | Meaning and example |
+-----------+--------------------------------------------------------------+
| \* | More than or equals to 0 character other than '/'. |
| | /var/log/samba/\* |
+-----------+--------------------------------------------------------------+
| \@ | More than or equals to 0 character other than '/' or '.'. |
| | /var/www/html/\@.html |
+-----------+--------------------------------------------------------------+
| \? | 1 byte character other than '/'. |
| | /tmp/mail.\?\?\?\?\?\? |
+-----------+--------------------------------------------------------------+
| \$ | More than or equals to 1 decimal digit. |
| | /proc/\$/cmdline |
+-----------+--------------------------------------------------------------+
| \+ | 1 decimal digit. |
| | /var/tmp/my_work.\+ |
+-----------+--------------------------------------------------------------+
| \X | More than or equals to 1 hexadecimal digit. |
| | /var/tmp/my-work.\X |
+-----------+--------------------------------------------------------------+
| \x | 1 hexadecimal digit. |
| | /tmp/my-work.\x |
+-----------+--------------------------------------------------------------+
| \A | More than or equals to 1 alphabet character. |
| | /var/log/my-work/\$-\A-\$.log |
+-----------+--------------------------------------------------------------+
| \a | 1 alphabet character. |
| | /home/users/\a/\*/public_html/\*.html |
+-----------+--------------------------------------------------------------+
| \- | Pathname subtraction operator. |
| | +---------------------+------------------------------------+ |
| | | Example | Meaning | |
| | +---------------------+------------------------------------+ |
| | | /etc/\* | All files in /etc/ directory. | |
| | +---------------------+------------------------------------+ |
| | | /etc/\*\-\*shadow\* | /etc/\* other than /etc/\*shadow\* | |
| | +---------------------+------------------------------------+ |
| | | /\*\-proc\-sys/ | /\*/ other than /proc/ /sys/ | |
| | +---------------------+------------------------------------+ |
+-----------+--------------------------------------------------------------+
+----------------+---------------------------------------------------------+
| Representation | Meaning and example |
+----------------+---------------------------------------------------------+
| \\ | backslash character itself. |
+----------------+---------------------------------------------------------+
| \ooo | 1 byte character. |
| | ooo is 001 <= ooo <= 040 || 177 <= ooo <= 377. |
| | |
| | \040 for space character. |
| | \177 for del character. |
| | |
+----------------+---------------------------------------------------------+
----- Part 5: Advantages -----
We can obtain extensibility.
Since our proposed approach adds \ to a character to interpret as a wild
card, we can introduce new wild card in future while maintaining backward
compatibility.
We can process monotonically.
Since our proposed approach separates strings using a space character,
we can split strings using existing string manipulation functions.
We can reliably analyze access logs.
It is guaranteed that a string doesn't contain space character (0x20) and
new line character (0x0A).
It is guaranteed that a string won't be converted by FTP and won't be damaged
by a terminal's settings.
It is guaranteed that a string won't be affected by encoding converters
(except encodings which insert NUL character (e.g. UTF-16)).
----- Part 6: conclusion -----
TOMOYO Linux is using its own encoding with reasons described above.
There is a disadvantage that we need to introduce a series of new string
manipulation functions. But TOMOYO Linux's encoding is useful for all users
(including audit and AppArmor) who want to perform pattern matching and
safely exchange string information between the kernel and the userspace.
-------------------- About policy interface --------------------
TOMOYO Linux creates the following files on securityfs (normally
mounted on /sys/kernel/security) as interfaces between kernel and
userspace. These files are for TOMOYO Linux management tools *only*,
not for general programs.
* profile
* exception_policy
* domain_policy
* manager
* meminfo
* self_domain
* version
* .domain_status
* .process_status
** /sys/kernel/security/tomoyo/profile **
This file is used to read or write profiles.
"profile" means a running mode of process. A profile lists up
functions and their modes in "$number-$variable=$value" format. The
$number is profile number between 0 and 255. Each domain is assigned
one profile. To assign profile to domains, use "ccs-setprofile" or
"ccs-editpolicy" or "ccs-loadpolicy" commands.
(Example)
[root@tomoyo]# cat /sys/kernel/security/tomoyo/profile
0-COMMENT=-----Disabled Mode-----
0-MAC_FOR_FILE=disabled
0-MAX_ACCEPT_ENTRY=2048
0-TOMOYO_VERBOSE=disabled
1-COMMENT=-----Learning Mode-----
1-MAC_FOR_FILE=learning
1-MAX_ACCEPT_ENTRY=2048
1-TOMOYO_VERBOSE=disabled
2-COMMENT=-----Permissive Mode-----
2-MAC_FOR_FILE=permissive
2-MAX_ACCEPT_ENTRY=2048
2-TOMOYO_VERBOSE=enabled
3-COMMENT=-----Enforcing Mode-----
3-MAC_FOR_FILE=enforcing
3-MAX_ACCEPT_ENTRY=2048
3-TOMOYO_VERBOSE=enabled
- MAC_FOR_FILE:
Specifies access control level regarding file access requests.
- MAX_ACCEPT_ENTRY:
Limits the max number of ACL entries that are automatically appended
during learning mode. Default is 2048.
- TOMOYO_VERBOSE:
Specifies whether to print domain policy violation messages or not.
** /sys/kernel/security/tomoyo/manager **
This file is used to read or append the list of programs or domains
that can write to /sys/kernel/security/tomoyo interface. By default,
only processes with both UID = 0 and EUID = 0 can modify policy via
/sys/kernel/security/tomoyo interface. You can use keyword
"manage_by_non_root" to allow policy modification by non root user.
(Example)
[root@tomoyo]# cat /sys/kernel/security/tomoyo/manager
/usr/lib/ccs/loadpolicy
/usr/lib/ccs/editpolicy
/usr/lib/ccs/setlevel
/usr/lib/ccs/setprofile
/usr/lib/ccs/ld-watch
/usr/lib/ccs/ccs-queryd
** /sys/kernel/security/tomoyo/exception_policy **
This file is used to read and write system global settings. Each line
has a directive and operand pair. Directives are listed below.
- initialize_domain:
To initialize domain transition when specific program is executed,
use initialize_domain directive.
* initialize_domain "program" from "domain"
* initialize_domain "program" from "the last program part of domain"
* initialize_domain "program"
If the part "from" and after is not given, the entry is applied to
all domain. If the "domain" doesn't start with "<kernel>", the entry
is applied to all domain whose domainname ends with "the last program
part of domain".
This directive is intended to aggregate domain transitions for daemon
program and program that are invoked by the kernel on demand, by
transiting to different domain.
- keep_domain
To prevent domain transition when program is executed from specific
domain, use keep_domain directive.
* keep_domain "program" from "domain"
* keep_domain "program" from "the last program part of domain"
* keep_domain "domain"
* keep_domain "the last program part of domain"
If the part "from" and before is not given, this entry is applied to
all program. If the "domain" doesn't start with "<kernel>", the entry
is applied to all domain whose domainname ends with "the last program
part of domain".
This directive is intended to reduce total number of domains and
memory usage by suppressing unneeded domain transitions.
To declare domain keepers, use keep_domain directive followed by
domain definition.
Any process that belongs to any domain declared with this directive,
the process stays at the same domain unless any program registered
with initialize_domain directive is executed.
In order to control domain transition in detail, you can use
no_keep_domain/no_initialize_domain keywrods.
- alias:
To allow executing programs using the name of symbolic links, use
alias keyword followed by dereferenced pathname and reference
pathname. For example, /sbin/pidof is a symbolic link to
/sbin/killall5 . In normal case, if /sbin/pidof is executed, the
domain is defined as if /sbin/killall5 is executed. By specifying
"alias /sbin/killall5 /sbin/pidof", you can run /sbin/pidof in the
domain for /sbin/pidof .
(Example)
alias /sbin/killall5 /sbin/pidof
- allow_read:
To grant unconditionally readable permissions, use allow_read keyword
followed by canonicalized file. This keyword is intended to reduce
size of domain policy by granting read access to library files such
as GLIBC and locale files. Exception is, if ignore_global_allow_read
keyword is given to a domain, entries specified by this keyword are
ignored.
(Example)
allow_read /lib/libc-2.5.so
- file_pattern:
To declare pathname pattern, use file_pattern keyword followed by
pathname pattern. The pathname pattern must be a canonicalized
Pathname. This keyword is not applicable to neither granting execute
permissions nor domain definitions.
For example, canonicalized pathname that contains a process ID
(i.e. /proc/PID/ files) needs to be grouped in order to make access
control work well.
(Example)
file_pattern /proc/\$/cmdline
- path_group
To declare pathname group, use path_group keyword followed by name of
the group and pathname pattern. For example, if you want to group all
files under home directory, you can define
path_group HOME-DIR-FILE /home/\*/\*
path_group HOME-DIR-FILE /home/\*/\*/\*
path_group HOME-DIR-FILE /home/\*/\*/\*/\*
in the exception policy and use like
allow_read @HOME-DIR-FILE
to grant file access permission.
- deny_rewrite:
To deny overwriting already written contents of file (such as log
files) by default, use deny_rewrite keyword followed by pathname
pattern. Files whose pathname match the patterns are not permitted to
open for writing without append mode or truncate unless the pathnames
are explicitly granted using allow_rewrite keyword in domain policy.
(Example)
deny_rewrite /var/log/\*
- aggregator
To deal multiple programs as a single program, use aggregator keyword
followed by name of original program and aggregated program. This
keyword is intended to aggregate similar programs.
For example, /usr/bin/tac and /bin/cat are similar. By specifying
"aggregator /usr/bin/tac /bin/cat", you can run /usr/bin/tac in the
domain for /bin/cat .
For example, /usr/sbin/logrotate for Fedora Core 3 generates programs
like /tmp/logrotate.\?\?\?\?\?\? and run them, but TOMOYO Linux
doesn't allow using patterns for granting execute permission and
defining domains. By specifying
"aggregator /tmp/logrotate.\?\?\?\?\?\? /tmp/logrotate.tmp", you can
run /tmp/logrotate.\?\?\?\?\?\? as if /tmp/logrotate.tmp is running.
** /sys/kernel/security/tomoyo/domain_policy **
This file contains definition of all domains and permissions that are
granted to each domain.
Lines from the next line to a domain definition ( any lines starting
with "<kernel>") to the previous line to the next domain definitions
are interpreted as access permissions for that domain.
** /sys/kernel/security/tomoyo/meminfo **
This file is to show the total RAM used to keep policy in the kernel
by TOMOYO Linux in bytes.
(Example)
[root@tomoyo]# cat /sys/kernel/security/tomoyo/meminfo
Shared: 61440
Private: 69632
Dynamic: 768
Total: 131840
You can set memory quota by writing to this file.
(Example)
[root@tomoyo]# echo Shared: 2097152 > /sys/kernel/security/tomoyo/meminfo
[root@tomoyo]# echo Private: 2097152 > /sys/kernel/security/tomoyo/meminfo
** /sys/kernel/security/tomoyo/self_domain **
This file is to show the name of domain the caller process belongs to.
(Example)
[root@etch]# cat /sys/kernel/security/tomoyo/self_domain
<kernel> /usr/sbin/sshd /bin/zsh /bin/cat
** /sys/kernel/security/tomoyo/version **
This file is used for getting TOMOYO Linux's version.
(Example)
[root@etch]# cat /sys/kernel/security/tomoyo/version
2.2.0-pre
** /sys/kernel/security/tomoyo/.domain_status **
This is a view (of a DBMS) that contains only profile number and
domainnames of domain so that "ccs-setprofile" command can do
line-oriented processing easily.
** /sys/kernel/security/tomoyo/.process_status **
This file is used by "ccs-ccstree" command to show "list of processes
currently running" and "domains which each process belongs to" and
"profile number which the domain is currently assigned" like "pstree"
command. This file is writable by programs that aren't registered as
policy manager.
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>
TOMOYO Linux performs pathname based access control.
To remove factors that make pathname based access control difficult
(e.g. symbolic links, "..", "//" etc.), TOMOYO Linux derives realpath
of requested pathname from "struct dentry" and "struct vfsmount".
The maximum length of string data is limited to 4000 including trailing '\0'.
Since TOMOYO Linux uses '\ooo' style representation for non ASCII printable
characters, maybe TOMOYO Linux should be able to support 16336 (which means
(NAME_MAX * (PATH_MAX / (NAME_MAX + 1)) * 4 + (PATH_MAX / (NAME_MAX + 1)))
including trailing '\0'), but I think 4000 is enough for practical use.
TOMOYO uses only 0x21 - 0x7E (as printable characters) and 0x20 (as word
delimiter) and 0x0A (as line delimiter).
0x01 - 0x20 and 0x80 - 0xFF is handled in \ooo style representation.
The reason to use \ooo is to guarantee that "%s" won't damage logs.
Userland program can request
open("/tmp/file granted.\nAccess /tmp/file ", O_WRONLY | O_CREAT, 0600)
and logging such crazy pathname using "Access %s denied.\n" format will cause
"fabrication of logs" like
Access /tmp/file granted.
Access /tmp/file denied.
TOMOYO converts such characters to \ooo so that the logs will become
Access /tmp/file\040granted.\012Access\040/tmp/file denied.
and the administrator can read the logs safely using /bin/cat .
Likewise, a crazy request like
open("/tmp/\x01\x02\x03\x04\x05\x06\x07\x08\x09", O_WRONLY | O_CREAT, 0600)
will be processed safely by converting to
Access /tmp/\001\002\003\004\005\006\007\010\011 denied.
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>
Based on discussions on linux-audit, as per Steve Grubb's request
http://lkml.org/lkml/2009/2/6/269, the following changes were made:
- forced audit result to be either 0 or 1.
- made template names const
- Added new stand-alone message type: AUDIT_INTEGRITY_RULE
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Acked-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
The number of calls to ima_path_check()/ima_file_free()
should be balanced. An extra call to fput(), indicates
the file could have been accessed without first being
measured.
Although f_count is incremented/decremented in places other
than fget/fput, like fget_light/fput_light and get_file, the
current task must already hold a file refcnt. The call to
__fput() is delayed until the refcnt becomes 0, resulting
in ima_file_free() flagging any changes.
- add hook to increment opencount for IPC shared memory(SYSV),
shmat files, and /dev/zero
- moved NULL iint test in opencount_get()
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Sequentialize access to the policy file
- permit multiple attempts to replace default policy with a valid policy
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Support for a user loadable policy through securityfs
with support for LSM specific policy data.
- free invalid rule in ima_parse_add_rule()
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Make the measurement lists available through securityfs.
- removed test for NULL return code from securityfs_create_file/dir
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
IMA provides hardware (TPM) based measurement and attestation for
file measurements. As the Trusted Computing (TPM) model requires,
IMA measures all files before they are accessed in any way (on the
integrity_bprm_check, integrity_path_check and integrity_file_mmap
hooks), and commits the measurements to the TPM. Once added to the
TPM, measurements can not be removed.
In addition, IMA maintains a list of these file measurements, which
can be used to validate the aggregate value stored in the TPM. The
TPM can sign these measurements, and thus the system can prove, to
itself and to a third party, the system's integrity in a way that
cannot be circumvented by malicious or compromised software.
- alloc ima_template_entry before calling ima_store_template()
- log ima_add_boot_aggregate() failure
- removed unused IMA_TEMPLATE_NAME_LEN
- replaced hard coded string length with #define name
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
If there is an error creating a file through securityfs_create_file,
NULL is not returned, rather the error is propagated.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove SELinux hooks which do nothing except defer to the capabilites
hooks (or in one case, replicates the function).
Signed-off-by: James Morris <jmorris@namei.org>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove secondary ops call to shm_shmat, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to unix_stream_connect, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to task_kill, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to task_setrlimit, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove unused cred_commit hook from SELinux. This
currently calls into the capabilities hook, which is a noop.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to task_create, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to file_mprotect, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to inode_setattr, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to inode_permission, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to inode_follow_link, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to inode_mknod, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to inode_unlink, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to inode_link, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to sb_umount, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to sb_mount, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to bprm_committed_creds, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove secondary ops call to bprm_committing_creds, which is
a noop in capabilities.
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Remove unused bprm_check_security hook from SELinux. This
currently calls into the capabilities hook, which is a noop.
Acked-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Given just how hard it is to find the code that uses MAY_APPEND
it's probably not a big surprise that this went unnoticed for so
long. The Smack rules loading code is incorrectly setting the
MAY_READ bit when MAY_APPEND is requested.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Context mounts and genfs labeled file systems behave differently with respect to
setting file system labels. This patch brings genfs labeled file systems in line
with context mounts in that setxattr calls to them should return EOPNOTSUPP and
fscreate calls will be ignored.
Signed-off-by: David P. Quigley <dpquigl@tycho.nsa.gov>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@macbook.localdomain>
There is no easy way to tell if a file system supports SELinux security labeling.
Because of this a new flag is being added to the super block security structure
to indicate that the particular super block supports labeling. This flag is set
for file systems using the xattr, task, and transition labeling methods unless
that behavior is overridden by context mounts.
Signed-off-by: David P. Quigley <dpquigl@tycho.nsa.gov>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@macbook.localdomain>
The super block security structure currently has three fields for what are
essentially flags. The flags field is used for mount options while two other
char fields are used for initialization and proc flags. These latter two fields are
essentially bit fields since the only used values are 0 and 1. These fields
have been collapsed into the flags field and new bit masks have been added for
them. The code is also fixed to work with these new flags.
Signed-off-by: David P. Quigley <dpquigl@tycho.nsa.gov>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@macbook.localdomain>
The devcgroup_inode_permission() hook in the devices whitelist cgroup has
always bypassed access checks on fifos. But the mknod hook did not. The
devices whitelist is only about block and char devices, and fifos can't
even be added to the whitelist, so fifos can't be created at all except by
tasks which have 'a' in their whitelist (meaning they have access to all
devices).
Fix the behavior by bypassing access checks to mkfifo.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: Paul Menage <menage@google.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: James Morris <jmorris@namei.org>
Reported-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: <stable@kernel.org> [2.6.27.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We should use list_for_each_entry_rcu in RCU read site.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Paul Menage <menage@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: Balbir Singh <balbir@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix a regression in cap_capable() due to:
commit 3b11a1dece
Author: David Howells <dhowells@redhat.com>
Date: Fri Nov 14 10:39:26 2008 +1100
CRED: Differentiate objective and effective subjective credentials on a task
The problem is that the above patch allows a process to have two sets of
credentials, and for the most part uses the subjective credentials when
accessing current's creds.
There is, however, one exception: cap_capable(), and thus capable(), uses the
real/objective credentials of the target task, whether or not it is the current
task.
Ordinarily this doesn't matter, since usually the two cred pointers in current
point to the same set of creds. However, sys_faccessat() makes use of this
facility to override the credentials of the calling process to make its test,
without affecting the creds as seen from other processes.
One of the things sys_faccessat() does is to make an adjustment to the
effective capabilities mask, which cap_capable(), as it stands, then ignores.
The affected capability check is in generic_permission():
if (!(mask & MAY_EXEC) || execute_ok(inode))
if (capable(CAP_DAC_OVERRIDE))
return 0;
This change passes the set of credentials to be tested down into the commoncap
and SELinux code. The security functions called by capable() and
has_capability() select the appropriate set of credentials from the process
being checked.
This can be tested by compiling the following program from the XFS testsuite:
/*
* t_access_root.c - trivial test program to show permission bug.
*
* Written by Michael Kerrisk - copyright ownership not pursued.
* Sourced from: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/6030.html
*/
#include <limits.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#define UID 500
#define GID 100
#define PERM 0
#define TESTPATH "/tmp/t_access"
static void
errExit(char *msg)
{
perror(msg);
exit(EXIT_FAILURE);
} /* errExit */
static void
accessTest(char *file, int mask, char *mstr)
{
printf("access(%s, %s) returns %d\n", file, mstr, access(file, mask));
} /* accessTest */
int
main(int argc, char *argv[])
{
int fd, perm, uid, gid;
char *testpath;
char cmd[PATH_MAX + 20];
testpath = (argc > 1) ? argv[1] : TESTPATH;
perm = (argc > 2) ? strtoul(argv[2], NULL, 8) : PERM;
uid = (argc > 3) ? atoi(argv[3]) : UID;
gid = (argc > 4) ? atoi(argv[4]) : GID;
unlink(testpath);
fd = open(testpath, O_RDWR | O_CREAT, 0);
if (fd == -1) errExit("open");
if (fchown(fd, uid, gid) == -1) errExit("fchown");
if (fchmod(fd, perm) == -1) errExit("fchmod");
close(fd);
snprintf(cmd, sizeof(cmd), "ls -l %s", testpath);
system(cmd);
if (seteuid(uid) == -1) errExit("seteuid");
accessTest(testpath, 0, "0");
accessTest(testpath, R_OK, "R_OK");
accessTest(testpath, W_OK, "W_OK");
accessTest(testpath, X_OK, "X_OK");
accessTest(testpath, R_OK | W_OK, "R_OK | W_OK");
accessTest(testpath, R_OK | X_OK, "R_OK | X_OK");
accessTest(testpath, W_OK | X_OK, "W_OK | X_OK");
accessTest(testpath, R_OK | W_OK | X_OK, "R_OK | W_OK | X_OK");
exit(EXIT_SUCCESS);
} /* main */
This can be run against an Ext3 filesystem as well as against an XFS
filesystem. If successful, it will show:
[root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
---------- 1 dhowells dhowells 0 2008-12-31 03:00 /tmp/xxx
access(/tmp/xxx, 0) returns 0
access(/tmp/xxx, R_OK) returns 0
access(/tmp/xxx, W_OK) returns 0
access(/tmp/xxx, X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK) returns 0
access(/tmp/xxx, R_OK | X_OK) returns -1
access(/tmp/xxx, W_OK | X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1
If unsuccessful, it will show:
[root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
---------- 1 dhowells dhowells 0 2008-12-31 02:56 /tmp/xxx
access(/tmp/xxx, 0) returns 0
access(/tmp/xxx, R_OK) returns -1
access(/tmp/xxx, W_OK) returns -1
access(/tmp/xxx, X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK) returns -1
access(/tmp/xxx, R_OK | X_OK) returns -1
access(/tmp/xxx, W_OK | X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1
I've also tested the fix with the SELinux and syscalls LTP testsuites.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: J. Bruce Fields <bfields@citi.umich.edu>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
inotify: fix type errors in interfaces
fix breakage in reiserfs_new_inode()
fix the treatment of jfs special inodes
vfs: remove duplicate code in get_fs_type()
add a vfs_fsync helper
sys_execve and sys_uselib do not call into fsnotify
zero i_uid/i_gid on inode allocation
inode->i_op is never NULL
ntfs: don't NULL i_op
isofs check for NULL ->i_op in root directory is dead code
affs: do not zero ->i_op
kill suid bit only for regular files
vfs: lseek(fd, 0, SEEK_CUR) race condition
... and don't bother in callers. Don't bother with zeroing i_blocks,
while we are at it - it's already been zeroed.
i_mode is not worth the effort; it has no common default value.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
We used to have rather schizophrenic set of checks for NULL ->i_op even
though it had been eliminated years ago. You'd need to go out of your
way to set it to NULL explicitly _and_ a bunch of code would die on
such inodes anyway. After killing two remaining places that still
did that bogosity, all that crap can go away.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
I started playing with pahole today and decided to put it against the
selinux structures. Found we could save a little bit of space on x86_64
(and no harm on i686) just reorganizing some structs.
Object size changes:
av_inherit: 24 -> 16
selinux_class_perm: 48 -> 40
context: 80 -> 72
Admittedly there aren't many of av_inherit or selinux_class_perm's in
the kernel (33 and 1 respectively) But the change to the size of struct
context reverberate out a bit. I can get some hard number if they are
needed, but I don't see why they would be. We do change which cacheline
context->len and context->str would be on, but I don't see that as a
problem since we are clearly going to have to load both if the context
is to be of any value. I've run with the patch and don't seem to be
having any problems.
An example of what's going on using struct av_inherit would be:
form: to:
struct av_inherit { struct av_inherit {
u16 tclass; const char **common_pts;
const char **common_pts; u32 common_base;
u32 common_base; u16 tclass;
};
(notice all I did was move u16 tclass to the end of the struct instead
of the beginning)
Memory layout before the change:
struct av_inherit {
u16 tclass; /* 2 */
/* 6 bytes hole */
const char** common_pts; /* 8 */
u32 common_base; /* 4 */
/* 4 byes padding */
/* size: 24, cachelines: 1 */
/* sum members: 14, holes: 1, sum holes: 6 */
/* padding: 4 */
};
Memory layout after the change:
struct av_inherit {
const char ** common_pts; /* 8 */
u32 common_base; /* 4 */
u16 tclass; /* 2 */
/* 2 bytes padding */
/* size: 16, cachelines: 1 */
/* sum members: 14, holes: 0, sum holes: 0 */
/* padding: 2 */
};
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Fix a regression in cap_capable() due to:
commit 5ff7711e635b32f0a1e558227d030c7e45b4a465
Author: David Howells <dhowells@redhat.com>
Date: Wed Dec 31 02:52:28 2008 +0000
CRED: Differentiate objective and effective subjective credentials on a task
The problem is that the above patch allows a process to have two sets of
credentials, and for the most part uses the subjective credentials when
accessing current's creds.
There is, however, one exception: cap_capable(), and thus capable(), uses the
real/objective credentials of the target task, whether or not it is the current
task.
Ordinarily this doesn't matter, since usually the two cred pointers in current
point to the same set of creds. However, sys_faccessat() makes use of this
facility to override the credentials of the calling process to make its test,
without affecting the creds as seen from other processes.
One of the things sys_faccessat() does is to make an adjustment to the
effective capabilities mask, which cap_capable(), as it stands, then ignores.
The affected capability check is in generic_permission():
if (!(mask & MAY_EXEC) || execute_ok(inode))
if (capable(CAP_DAC_OVERRIDE))
return 0;
This change splits capable() from has_capability() down into the commoncap and
SELinux code. The capable() security op now only deals with the current
process, and uses the current process's subjective creds. A new security op -
task_capable() - is introduced that can check any task's objective creds.
strictly the capable() security op is superfluous with the presence of the
task_capable() op, however it should be faster to call the capable() op since
two fewer arguments need be passed down through the various layers.
This can be tested by compiling the following program from the XFS testsuite:
/*
* t_access_root.c - trivial test program to show permission bug.
*
* Written by Michael Kerrisk - copyright ownership not pursued.
* Sourced from: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/6030.html
*/
#include <limits.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#define UID 500
#define GID 100
#define PERM 0
#define TESTPATH "/tmp/t_access"
static void
errExit(char *msg)
{
perror(msg);
exit(EXIT_FAILURE);
} /* errExit */
static void
accessTest(char *file, int mask, char *mstr)
{
printf("access(%s, %s) returns %d\n", file, mstr, access(file, mask));
} /* accessTest */
int
main(int argc, char *argv[])
{
int fd, perm, uid, gid;
char *testpath;
char cmd[PATH_MAX + 20];
testpath = (argc > 1) ? argv[1] : TESTPATH;
perm = (argc > 2) ? strtoul(argv[2], NULL, 8) : PERM;
uid = (argc > 3) ? atoi(argv[3]) : UID;
gid = (argc > 4) ? atoi(argv[4]) : GID;
unlink(testpath);
fd = open(testpath, O_RDWR | O_CREAT, 0);
if (fd == -1) errExit("open");
if (fchown(fd, uid, gid) == -1) errExit("fchown");
if (fchmod(fd, perm) == -1) errExit("fchmod");
close(fd);
snprintf(cmd, sizeof(cmd), "ls -l %s", testpath);
system(cmd);
if (seteuid(uid) == -1) errExit("seteuid");
accessTest(testpath, 0, "0");
accessTest(testpath, R_OK, "R_OK");
accessTest(testpath, W_OK, "W_OK");
accessTest(testpath, X_OK, "X_OK");
accessTest(testpath, R_OK | W_OK, "R_OK | W_OK");
accessTest(testpath, R_OK | X_OK, "R_OK | X_OK");
accessTest(testpath, W_OK | X_OK, "W_OK | X_OK");
accessTest(testpath, R_OK | W_OK | X_OK, "R_OK | W_OK | X_OK");
exit(EXIT_SUCCESS);
} /* main */
This can be run against an Ext3 filesystem as well as against an XFS
filesystem. If successful, it will show:
[root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
---------- 1 dhowells dhowells 0 2008-12-31 03:00 /tmp/xxx
access(/tmp/xxx, 0) returns 0
access(/tmp/xxx, R_OK) returns 0
access(/tmp/xxx, W_OK) returns 0
access(/tmp/xxx, X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK) returns 0
access(/tmp/xxx, R_OK | X_OK) returns -1
access(/tmp/xxx, W_OK | X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1
If unsuccessful, it will show:
[root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
---------- 1 dhowells dhowells 0 2008-12-31 02:56 /tmp/xxx
access(/tmp/xxx, 0) returns 0
access(/tmp/xxx, R_OK) returns -1
access(/tmp/xxx, W_OK) returns -1
access(/tmp/xxx, X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK) returns -1
access(/tmp/xxx, R_OK | X_OK) returns -1
access(/tmp/xxx, W_OK | X_OK) returns -1
access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1
I've also tested the fix with the SELinux and syscalls LTP testsuites.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Don't store the field->op in the messy (and very inconvenient for e.g.
audit_comparator()) form; translate to dense set of values and do full
validation of userland-submitted value while we are at it.
->audit_init_rule() and ->audit_match_rule() get new values now; in-tree
instances updated.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* 'cpus4096-for-linus-3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (77 commits)
x86: setup_per_cpu_areas() cleanup
cpumask: fix compile error when CONFIG_NR_CPUS is not defined
cpumask: use alloc_cpumask_var_node where appropriate
cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_t
x86: use cpumask_var_t in acpi/boot.c
x86: cleanup some remaining usages of NR_CPUS where s/b nr_cpu_ids
sched: put back some stack hog changes that were undone in kernel/sched.c
x86: enable cpus display of kernel_max and offlined cpus
ia64: cpumask fix for is_affinity_mask_valid()
cpumask: convert RCU implementations, fix
xtensa: define __fls
mn10300: define __fls
m32r: define __fls
h8300: define __fls
frv: define __fls
cris: define __fls
cpumask: CONFIG_DISABLE_OBSOLETE_CPUMASK_FUNCTIONS
cpumask: zero extra bits in alloc_cpumask_var_node
cpumask: replace for_each_cpu_mask_nr with for_each_cpu in kernel/time/
cpumask: convert mm/
...
Impact: cleanup
In future, all cpumask ops will only be valid (in general) for bit
numbers < nr_cpu_ids. So use that instead of NR_CPUS in iterators
and other comparisons.
This is always safe: no cpu number can be >= nr_cpu_ids, and
nr_cpu_ids is initialized to NR_CPUS at boot.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Acked-by: James Morris <jmorris@namei.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Fix the following sparse warning:
CC security/keys/key.o
security/keys/keyctl.c:1297:10: warning: incorrect type in argument 2 (different address spaces)
security/keys/keyctl.c:1297:10: expected char [noderef] <asn:1>*buffer
security/keys/keyctl.c:1297:10: got char *<noident>
which appears to be caused by lack of __user annotation to the cast of
a syscall argument.
Signed-off-by: James Morris <jmorris@namei.org>
Acked-by: David Howells <dhowells@redhat.com>
Add new LSM hooks for path-based checks. Call them on directory-modifying
operations at the points where we still know the vfsmount involved.
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: Al Viro <viro@zeniv.linux.org.uk>
Add support for unlabeled network hosts and networks.
Relies heavily on Paul Moore's netlabel support.
Creates a new entry in /smack called netlabel. Writes to /smack/netlabel
take the form:
A.B.C.D LABEL
or
A.B.C.D/N LABEL
where A.B.C.D is a network address, N is an integer between 0-32,
and LABEL is the Smack label to be used. If /N is omitted /32 is
assumed. N designates the netmask for the address. Entries are
matched by the most specific address/mask pair. 0.0.0.0/0 will
match everything, while 192.168.1.117/32 will match exactly one
host.
A new system label "@", pronounced "web", is defined. Processes
can not be assigned the web label. An address assigned the web
label can be written to by any process, and packets coming from
a web address can be written to any socket. Use of the web label
is a violation of any strict MAC policy, but the web label has
been requested many times.
The nltype entry has been removed from /smack. It did not work right
and the netlabel interface can be used to specify that all hosts
be treated as unlabeled.
CIPSO labels on incoming packets will be honored, even from designated
single label hosts. Single label hosts can only be written to by
processes with labels that can write to the label of the host.
Packets sent to single label hosts will always be unlabeled.
Once added a single label designation cannot be removed, however
the label may be changed.
The behavior of the ambient label remains unchanged.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul.moore@hp.com>
This patch is the first step towards removing the old "compat_net" code from
the kernel. Secmark, the "compat_net" replacement was first introduced in
2.6.18 (September 2006) and the major Linux distributions with SELinux support
have transitioned to Secmark so it is time to start deprecating the "compat_net"
mechanism. Testing a patched version of 2.6.28-rc6 with the initial release of
Fedora Core 5 did not show any problems when running in enforcing mode.
This patch adds an entry to the feature-removal-schedule.txt file and removes
the SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT configuration option, forcing
Secmark on by default although it can still be disabled at runtime. The patch
also makes the Secmark permission checks "dynamic" in the sense that they are
only executed when Secmark is configured; this should help prevent problems
with older distributions that have not yet migrated to Secmark.
Signed-off-by: Paul Moore <paul.moore@hp.com>
Acked-by: James Morris <jmorris@namei.org>
Update the NetLabel kernel API to expose the new features added in kernel
releases 2.6.25 and 2.6.28: the static/fallback label functionality and network
address based selectors.
Signed-off-by: Paul Moore <paul.moore@hp.com>
Fix variable uninitialisation warnings introduced in:
commit 8bbf4976b5
Author: David Howells <dhowells@redhat.com>
Date: Fri Nov 14 10:39:14 2008 +1100
KEYS: Alter use of key instantiation link-to-keyring argument
As:
security/keys/keyctl.c: In function 'keyctl_negate_key':
security/keys/keyctl.c:976: warning: 'dest_keyring' may be used uninitialized in this function
security/keys/keyctl.c: In function 'keyctl_instantiate_key':
security/keys/keyctl.c:898: warning: 'dest_keyring' may be used uninitialized in this function
Some versions of gcc notice that get_instantiation_key() doesn't always set
*_dest_keyring, but fail to observe that if this happens then *_dest_keyring
will not be read by the caller.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1429 commits)
net: Allow dependancies of FDDI & Tokenring to be modular.
igb: Fix build warning when DCA is disabled.
net: Fix warning fallout from recent NAPI interface changes.
gro: Fix potential use after free
sfc: If AN is enabled, always read speed/duplex from the AN advertising bits
sfc: When disabling the NIC, close the device rather than unregistering it
sfc: SFT9001: Add cable diagnostics
sfc: Add support for multiple PHY self-tests
sfc: Merge top-level functions for self-tests
sfc: Clean up PHY mode management in loopback self-test
sfc: Fix unreliable link detection in some loopback modes
sfc: Generate unique names for per-NIC workqueues
802.3ad: use standard ethhdr instead of ad_header
802.3ad: generalize out mac address initializer
802.3ad: initialize ports LACPDU from const initializer
802.3ad: remove typedef around ad_system
802.3ad: turn ports is_individual into a bool
802.3ad: turn ports is_enabled into a bool
802.3ad: make ntt bool
ixgbe: Fix set_ringparam in ixgbe to use the same memory pools.
...
Fixed trivial IPv4/6 address printing conflicts in fs/cifs/connect.c due
to the conversion to %pI (in this networking merge) and the addition of
doing IPv6 addresses (from the earlier merge of CIFS).
smackfs: check for allocation failures in smk_set_access()
While adding a new subject/object pair to smack_list, smk_set_access()
didn't check the return of kzalloc().
This patch changes smk_set_access() to return 0 or -ENOMEM, based on
kzalloc()'s return. It also updates its caller, smk_write_load(), to
check for smk_set_access()'s return, given it is no longer a void
return function.
Signed-off-by: Sergio Luis <sergio@larces.uece.br>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Ahmed S. Darwish <darwish.07@gmail.com>
Cc: LSM <linux-security-module@vger.kernel.org>
Cc: LKLM <linux-kernel@vger.kernel.org>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Don't bother checking permissions when the kernel performs an
internal mount, as this should always be allowed.
Signed-off-by: James Morris <jmorris@namei.org>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Pass mount flags to security_sb_kern_mount(), so security modules
can determine if a mount operation is being performed by the kernel.
Signed-off-by: James Morris <jmorris@namei.org>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
When CONFIG_SECURITY_FILE_CAPABILITIES is not set the audit system may
try to call into the capabilities function vfs_cap_from_file. This
patch defines that function so kernels can build and work.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Allow kernel services to override LSM settings appropriate to the actions
performed by a task by duplicating a set of credentials, modifying it and then
using task_struct::cred to point to it when performing operations on behalf of
a task.
This is used, for example, by CacheFiles which has to transparently access the
cache on behalf of a process that thinks it is doing, say, NFS accesses with a
potentially inappropriate (with respect to accessing the cache) set of
credentials.
This patch provides two LSM hooks for modifying a task security record:
(*) security_kernel_act_as() which allows modification of the security datum
with which a task acts on other objects (most notably files).
(*) security_kernel_create_files_as() which allows modification of the
security datum that is used to initialise the security data on a file that
a task creates.
The patch also provides four new credentials handling functions, which wrap the
LSM functions:
(1) prepare_kernel_cred()
Prepare a set of credentials for a kernel service to use, based either on
a daemon's credentials or on init_cred. All the keyrings are cleared.
(2) set_security_override()
Set the LSM security ID in a set of credentials to a specific security
context, assuming permission from the LSM policy.
(3) set_security_override_from_ctx()
As (2), but takes the security context as a string.
(4) set_create_files_as()
Set the file creation LSM security ID in a set of credentials to be the
same as that on a particular inode.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> [Smack changes]
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Add a 'kernel_service' object class to SELinux and give this object class two
access vectors: 'use_as_override' and 'create_files_as'.
The first vector is used to grant a process the right to nominate an alternate
process security ID for the kernel to use as an override for the SELinux
subjective security when accessing stuff on behalf of another process.
For example, CacheFiles when accessing the cache on behalf on a process
accessing an NFS file needs to use a subjective security ID appropriate to the
cache rather then the one the calling process is using. The cachefilesd
daemon will nominate the security ID to be used.
The second vector is used to grant a process the right to nominate a file
creation label for a kernel service to use.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Differentiate the objective and real subjective credentials from the effective
subjective credentials on a task by introducing a second credentials pointer
into the task_struct.
task_struct::real_cred then refers to the objective and apparent real
subjective credentials of a task, as perceived by the other tasks in the
system.
task_struct::cred then refers to the effective subjective credentials of a
task, as used by that task when it's actually running. These are not visible
to the other tasks in the system.
__task_cred(task) then refers to the objective/real credentials of the task in
question.
current_cred() refers to the effective subjective credentials of the current
task.
prepare_creds() uses the objective creds as a base and commit_creds() changes
both pointers in the task_struct (indeed commit_creds() requires them to be the
same).
override_creds() and revert_creds() change the subjective creds pointer only,
and the former returns the old subjective creds. These are used by NFSD,
faccessat() and do_coredump(), and will by used by CacheFiles.
In SELinux, current_has_perm() is provided as an alternative to
task_has_perm(). This uses the effective subjective context of current,
whereas task_has_perm() uses the objective/real context of the subject.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Make execve() take advantage of copy-on-write credentials, allowing it to set
up the credentials in advance, and then commit the whole lot after the point
of no return.
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
(1) execve().
The credential bits from struct linux_binprm are, for the most part,
replaced with a single credentials pointer (bprm->cred). This means that
all the creds can be calculated in advance and then applied at the point
of no return with no possibility of failure.
I would like to replace bprm->cap_effective with:
cap_isclear(bprm->cap_effective)
but this seems impossible due to special behaviour for processes of pid 1
(they always retain their parent's capability masks where normally they'd
be changed - see cap_bprm_set_creds()).
The following sequence of events now happens:
(a) At the start of do_execve, the current task's cred_exec_mutex is
locked to prevent PTRACE_ATTACH from obsoleting the calculation of
creds that we make.
(a) prepare_exec_creds() is then called to make a copy of the current
task's credentials and prepare it. This copy is then assigned to
bprm->cred.
This renders security_bprm_alloc() and security_bprm_free()
unnecessary, and so they've been removed.
(b) The determination of unsafe execution is now performed immediately
after (a) rather than later on in the code. The result is stored in
bprm->unsafe for future reference.
(c) prepare_binprm() is called, possibly multiple times.
(i) This applies the result of set[ug]id binaries to the new creds
attached to bprm->cred. Personality bit clearance is recorded,
but now deferred on the basis that the exec procedure may yet
fail.
(ii) This then calls the new security_bprm_set_creds(). This should
calculate the new LSM and capability credentials into *bprm->cred.
This folds together security_bprm_set() and parts of
security_bprm_apply_creds() (these two have been removed).
Anything that might fail must be done at this point.
(iii) bprm->cred_prepared is set to 1.
bprm->cred_prepared is 0 on the first pass of the security
calculations, and 1 on all subsequent passes. This allows SELinux
in (ii) to base its calculations only on the initial script and
not on the interpreter.
(d) flush_old_exec() is called to commit the task to execution. This
performs the following steps with regard to credentials:
(i) Clear pdeath_signal and set dumpable on certain circumstances that
may not be covered by commit_creds().
(ii) Clear any bits in current->personality that were deferred from
(c.i).
(e) install_exec_creds() [compute_creds() as was] is called to install the
new credentials. This performs the following steps with regard to
credentials:
(i) Calls security_bprm_committing_creds() to apply any security
requirements, such as flushing unauthorised files in SELinux, that
must be done before the credentials are changed.
This is made up of bits of security_bprm_apply_creds() and
security_bprm_post_apply_creds(), both of which have been removed.
This function is not allowed to fail; anything that might fail
must have been done in (c.ii).
(ii) Calls commit_creds() to apply the new credentials in a single
assignment (more or less). Possibly pdeath_signal and dumpable
should be part of struct creds.
(iii) Unlocks the task's cred_replace_mutex, thus allowing
PTRACE_ATTACH to take place.
(iv) Clears The bprm->cred pointer as the credentials it was holding
are now immutable.
(v) Calls security_bprm_committed_creds() to apply any security
alterations that must be done after the creds have been changed.
SELinux uses this to flush signals and signal handlers.
(f) If an error occurs before (d.i), bprm_free() will call abort_creds()
to destroy the proposed new credentials and will then unlock
cred_replace_mutex. No changes to the credentials will have been
made.
(2) LSM interface.
A number of functions have been changed, added or removed:
(*) security_bprm_alloc(), ->bprm_alloc_security()
(*) security_bprm_free(), ->bprm_free_security()
Removed in favour of preparing new credentials and modifying those.
(*) security_bprm_apply_creds(), ->bprm_apply_creds()
(*) security_bprm_post_apply_creds(), ->bprm_post_apply_creds()
Removed; split between security_bprm_set_creds(),
security_bprm_committing_creds() and security_bprm_committed_creds().
(*) security_bprm_set(), ->bprm_set_security()
Removed; folded into security_bprm_set_creds().
(*) security_bprm_set_creds(), ->bprm_set_creds()
New. The new credentials in bprm->creds should be checked and set up
as appropriate. bprm->cred_prepared is 0 on the first call, 1 on the
second and subsequent calls.
(*) security_bprm_committing_creds(), ->bprm_committing_creds()
(*) security_bprm_committed_creds(), ->bprm_committed_creds()
New. Apply the security effects of the new credentials. This
includes closing unauthorised files in SELinux. This function may not
fail. When the former is called, the creds haven't yet been applied
to the process; when the latter is called, they have.
The former may access bprm->cred, the latter may not.
(3) SELinux.
SELinux has a number of changes, in addition to those to support the LSM
interface changes mentioned above:
(a) The bprm_security_struct struct has been removed in favour of using
the credentials-under-construction approach.
(c) flush_unauthorized_files() now takes a cred pointer and passes it on
to inode_has_perm(), file_has_perm() and dentry_open().
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Inaugurate copy-on-write credentials management. This uses RCU to manage the
credentials pointer in the task_struct with respect to accesses by other tasks.
A process may only modify its own credentials, and so does not need locking to
access or modify its own credentials.
A mutex (cred_replace_mutex) is added to the task_struct to control the effect
of PTRACE_ATTACHED on credential calculations, particularly with respect to
execve().
With this patch, the contents of an active credentials struct may not be
changed directly; rather a new set of credentials must be prepared, modified
and committed using something like the following sequence of events:
struct cred *new = prepare_creds();
int ret = blah(new);
if (ret < 0) {
abort_creds(new);
return ret;
}
return commit_creds(new);
There are some exceptions to this rule: the keyrings pointed to by the active
credentials may be instantiated - keyrings violate the COW rule as managing
COW keyrings is tricky, given that it is possible for a task to directly alter
the keys in a keyring in use by another task.
To help enforce this, various pointers to sets of credentials, such as those in
the task_struct, are declared const. The purpose of this is compile-time
discouragement of altering credentials through those pointers. Once a set of
credentials has been made public through one of these pointers, it may not be
modified, except under special circumstances:
(1) Its reference count may incremented and decremented.
(2) The keyrings to which it points may be modified, but not replaced.
The only safe way to modify anything else is to create a replacement and commit
using the functions described in Documentation/credentials.txt (which will be
added by a later patch).
This patch and the preceding patches have been tested with the LTP SELinux
testsuite.
This patch makes several logical sets of alteration:
(1) execve().
This now prepares and commits credentials in various places in the
security code rather than altering the current creds directly.
(2) Temporary credential overrides.
do_coredump() and sys_faccessat() now prepare their own credentials and
temporarily override the ones currently on the acting thread, whilst
preventing interference from other threads by holding cred_replace_mutex
on the thread being dumped.
This will be replaced in a future patch by something that hands down the
credentials directly to the functions being called, rather than altering
the task's objective credentials.
(3) LSM interface.
A number of functions have been changed, added or removed:
(*) security_capset_check(), ->capset_check()
(*) security_capset_set(), ->capset_set()
Removed in favour of security_capset().
(*) security_capset(), ->capset()
New. This is passed a pointer to the new creds, a pointer to the old
creds and the proposed capability sets. It should fill in the new
creds or return an error. All pointers, barring the pointer to the
new creds, are now const.
(*) security_bprm_apply_creds(), ->bprm_apply_creds()
Changed; now returns a value, which will cause the process to be
killed if it's an error.
(*) security_task_alloc(), ->task_alloc_security()
Removed in favour of security_prepare_creds().
(*) security_cred_free(), ->cred_free()
New. Free security data attached to cred->security.
(*) security_prepare_creds(), ->cred_prepare()
New. Duplicate any security data attached to cred->security.
(*) security_commit_creds(), ->cred_commit()
New. Apply any security effects for the upcoming installation of new
security by commit_creds().
(*) security_task_post_setuid(), ->task_post_setuid()
Removed in favour of security_task_fix_setuid().
(*) security_task_fix_setuid(), ->task_fix_setuid()
Fix up the proposed new credentials for setuid(). This is used by
cap_set_fix_setuid() to implicitly adjust capabilities in line with
setuid() changes. Changes are made to the new credentials, rather
than the task itself as in security_task_post_setuid().
(*) security_task_reparent_to_init(), ->task_reparent_to_init()
Removed. Instead the task being reparented to init is referred
directly to init's credentials.
NOTE! This results in the loss of some state: SELinux's osid no
longer records the sid of the thread that forked it.
(*) security_key_alloc(), ->key_alloc()
(*) security_key_permission(), ->key_permission()
Changed. These now take cred pointers rather than task pointers to
refer to the security context.
(4) sys_capset().
This has been simplified and uses less locking. The LSM functions it
calls have been merged.
(5) reparent_to_kthreadd().
This gives the current thread the same credentials as init by simply using
commit_thread() to point that way.
(6) __sigqueue_alloc() and switch_uid()
__sigqueue_alloc() can't stop the target task from changing its creds
beneath it, so this function gets a reference to the currently applicable
user_struct which it then passes into the sigqueue struct it returns if
successful.
switch_uid() is now called from commit_creds(), and possibly should be
folded into that. commit_creds() should take care of protecting
__sigqueue_alloc().
(7) [sg]et[ug]id() and co and [sg]et_current_groups.
The set functions now all use prepare_creds(), commit_creds() and
abort_creds() to build and check a new set of credentials before applying
it.
security_task_set[ug]id() is called inside the prepared section. This
guarantees that nothing else will affect the creds until we've finished.
The calling of set_dumpable() has been moved into commit_creds().
Much of the functionality of set_user() has been moved into
commit_creds().
The get functions all simply access the data directly.
(8) security_task_prctl() and cap_task_prctl().
security_task_prctl() has been modified to return -ENOSYS if it doesn't
want to handle a function, or otherwise return the return value directly
rather than through an argument.
Additionally, cap_task_prctl() now prepares a new set of credentials, even
if it doesn't end up using it.
(9) Keyrings.
A number of changes have been made to the keyrings code:
(a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
all been dropped and built in to the credentials functions directly.
They may want separating out again later.
(b) key_alloc() and search_process_keyrings() now take a cred pointer
rather than a task pointer to specify the security context.
(c) copy_creds() gives a new thread within the same thread group a new
thread keyring if its parent had one, otherwise it discards the thread
keyring.
(d) The authorisation key now points directly to the credentials to extend
the search into rather pointing to the task that carries them.
(e) Installing thread, process or session keyrings causes a new set of
credentials to be created, even though it's not strictly necessary for
process or session keyrings (they're shared).
(10) Usermode helper.
The usermode helper code now carries a cred struct pointer in its
subprocess_info struct instead of a new session keyring pointer. This set
of credentials is derived from init_cred and installed on the new process
after it has been cloned.
call_usermodehelper_setup() allocates the new credentials and
call_usermodehelper_freeinfo() discards them if they haven't been used. A
special cred function (prepare_usermodeinfo_creds()) is provided
specifically for call_usermodehelper_setup() to call.
call_usermodehelper_setkeys() adjusts the credentials to sport the
supplied keyring as the new session keyring.
(11) SELinux.
SELinux has a number of changes, in addition to those to support the LSM
interface changes mentioned above:
(a) selinux_setprocattr() no longer does its check for whether the
current ptracer can access processes with the new SID inside the lock
that covers getting the ptracer's SID. Whilst this lock ensures that
the check is done with the ptracer pinned, the result is only valid
until the lock is released, so there's no point doing it inside the
lock.
(12) is_single_threaded().
This function has been extracted from selinux_setprocattr() and put into
a file of its own in the lib/ directory as join_session_keyring() now
wants to use it too.
The code in SELinux just checked to see whether a task shared mm_structs
with other tasks (CLONE_VM), but that isn't good enough. We really want
to know if they're part of the same thread group (CLONE_THREAD).
(13) nfsd.
The NFS server daemon now has to use the COW credentials to set the
credentials it is going to use. It really needs to pass the credentials
down to the functions it calls, but it can't do that until other patches
in this series have been applied.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Pass credentials through dentry_open() so that the COW creds patch can have
SELinux's flush_unauthorized_files() pass the appropriate creds back to itself
when it opens its null chardev.
The security_dentry_open() call also now takes a creds pointer, as does the
dentry_open hook in struct security_operations.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Make inode_has_perm() and file_has_perm() take a cred pointer rather than a
task pointer.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Separate per-task-group keyrings from signal_struct and dangle their anchor
from the cred struct rather than the signal_struct.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Wrap access to SELinux's task SID, using task_sid() and current_sid() as
appropriate.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Use RCU to access another task's creds and to release a task's own creds.
This means that it will be possible for the credentials of a task to be
replaced without another task (a) requiring a full lock to read them, and (b)
seeing deallocated memory.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Wrap current->cred and a few other accessors to hide their actual
implementation.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Detach the credentials from task_struct, duplicating them in copy_process()
and releasing them in __put_task_struct().
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Separate the task security context from task_struct. At this point, the
security data is temporarily embedded in the task_struct with two pointers
pointing to it.
Note that the Alpha arch is altered as it refers to (E)UID and (E)GID in
entry.S via asm-offsets.
With comment fixes Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Constify the kernel_cap_t arguments to the capset LSM hooks.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Take away the ability for sys_capset() to affect processes other than current.
This means that current will not need to lock its own credentials when reading
them against interference by other processes.
This has effectively been the case for a while anyway, since:
(1) Without LSM enabled, sys_capset() is disallowed.
(2) With file-based capabilities, sys_capset() is neutered.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments. Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist. This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
(1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
keyring by ID (ringid >= 0), then that keyring will be used.
(2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
special constants that refer to the requesting process's keyrings
(KEY_SPEC_*_KEYRING, all <= 0), then:
(a) If sys_request_key() was given a keyring to use (destringid) then the
key will be attached to that keyring.
(b) If sys_request_key() was given a NULL keyring, then the key being
instantiated will be attached to the default keyring as set by
keyctl_set_reqkey_keyring().
(3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained. This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
+-----------+ +--------------+ +--------------+
| | | | | |
| Requestor |------->| Instantiator |------->| Instantiator |
| | | | | |
+-----------+ +--------------+ +--------------+
request_key() request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch. The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator. To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Disperse the bits of linux/key_ui.h as the reason they were put here (keyfs)
didn't get in.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
Wrap access to task credentials so that they can be separated more easily from
the task_struct during the introduction of COW creds.
Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().
Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
sense to use RCU directly rather than a convenient wrapper; these will be
addressed by later patches.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Cc: Andrew G. Morgan <morgan@kernel.org>
Signed-off-by: James Morris <jmorris@namei.org>
Wrap access to task credentials so that they can be separated more easily from
the task_struct during the introduction of COW creds.
Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().
Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
sense to use RCU directly rather than a convenient wrapper; these will be
addressed by later patches.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
check when determining if a process has additional powers to override
memory limits or when trying to read/write illegal file labels. Use
the new noaudit call instead.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
make an A or B type decision instead of a security decision. Currently
this is the case at least for filesystems when deciding if a process can use
the reserved 'root' blocks and for the case of things like the oom
algorithm determining if processes are root processes and should be less
likely to be killed. These types of security system requests should not be
audited or logged since they are not really security decisions. It would be
possible to solve this problem like the vm_enough_memory security check did
by creating a new LSM interface and moving all of the policy into that
interface but proves the needlessly bloat the LSM and provide complex
indirection.
This merely allows those decisions to be made where they belong and to not
flood logs or printk with denials for thing that are not security decisions.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
non-zero pE we will crate a new audit record which contains the entire set
of known information about the executable in question, fP, fI, fE, fversion
and includes the process's pE, pI, pP. Before and after the bprm capability
are applied. This record type will only be emitted from execve syscalls.
an example of making ping use fcaps instead of setuid:
setcap "cat_net_raw+pe" /bin/ping
type=SYSCALL msg=audit(1225742021.015:236): arch=c000003e syscall=59 success=yes exit=0 a0=1457f30 a1=14606b0 a2=1463940 a3=321b770a70 items=2 ppid=2929 pid=2963 auid=0 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=3 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=UNKNOWN[1321] msg=audit(1225742021.015:236): fver=2 fp=0000000000002000 fi=0000000000000000 fe=1 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=0000000000002000 new_pi=0000000000000000 new_pe=0000000000002000
type=EXECVE msg=audit(1225742021.015:236): argc=2 a0="ping" a1="127.0.0.1"
type=CWD msg=audit(1225742021.015:236): cwd="/home/test"
type=PATH msg=audit(1225742021.015:236): item=0 name="/bin/ping" inode=49256 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fp=0000000000002000 cap_fe=1 cap_fver=2
type=PATH msg=audit(1225742021.015:236): item=1 name=(null) inode=507915 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
functions which retrieve fcaps information from disk. This information is
necessary so fcaps information can be collected and recorded by the audit
system.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Make request_key() instantiate the per-user keyrings so that it doesn't oops
if it needs to get hold of the user session keyring because there isn't a
session keyring in place.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Steve French <smfrench@gmail.com>
Tested-by: Rutger Nijlunsing <rutger.nijlunsing@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently when SELinux has not been updated to handle a netlink message
type the operation is denied with EINVAL. This patch will leave the
audit/warning message so things get fixed but if policy chose to allow
unknowns this will allow the netlink operation.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
Add a no_file_caps boot option when file capabilities are
compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).
This allows distributions to ship a kernel with file capabilities
compiled in, without forcing users to use (and understand and
trust) them.
When no_file_caps is specified at boot, then when a process executes
a file, any file capabilities stored with that file will not be
used in the calculation of the process' new capability sets.
This means that booting with the no_file_caps boot option will
not be the same as booting a kernel with file capabilities
compiled out - in particular a task with CAP_SETPCAP will not
have any chance of passing capabilities to another task (which
isn't "really" possible anyway, and which may soon by killed
altogether by David Howells in any case), and it will instead
be able to put new capabilities in its pI. However since fI
will always be empty and pI is masked with fI, it gains the
task nothing.
We also support the extra prctl options, setting securebits and
dropping capabilities from the per-process bounding set.
The other remaining difference is that killpriv, task_setscheduler,
setioprio, and setnice will continue to be hooked. That will
be noticable in the case where a root task changed its uid
while keeping some caps, and another task owned by the new uid
tries to change settings for the more privileged task.
Changelog:
Nov 05 2008: (v4) trivial port on top of always-start-\
with-clear-caps patch
Sep 23 2008: nixed file_caps_enabled when file caps are
not compiled in as it isn't used.
Document no_file_caps in kernel-parameters.txt.
Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Signed-off-by: James Morris <jmorris@namei.org>
In enforcing mode '/sbin/ip addrlabel' results in a SELinux error:
type=SELINUX_ERR msg=audit(1225698822.073:42): SELinux: unrecognized
netlink message type=74 for sclass=43
The problem is missing RTM_*ADDRLABEL entries in SELinux's netlink
message types table.
Reported in https://bugzilla.redhat.com/show_bug.cgi?id=469423
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
