Eric Lee / smarc-fsl-linux-kernel

02 Sep, 2009

1 commit

  • ee18d64c1   KEYS: Add a keyctl to install a process's session keyring on its parent [try #6] ... Browse Code »

    Add a keyctl to install a process's session keyring onto its parent. This
    replaces the parent's session keyring. Because the COW credential code does
    not permit one process to change another process's credentials directly, the
    change is deferred until userspace next starts executing again. Normally this
    will be after a wait*() syscall.

    To support this, three new security hooks have been provided:
    cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
    the blank security creds and key_session_to_parent() - which asks the LSM if
    the process may replace its parent's session keyring.

    The replacement may only happen if the process has the same ownership details
    as its parent, and the process has LINK permission on the session keyring, and
    the session keyring is owned by the process, and the LSM permits it.

    Note that this requires alteration to each architecture's notify_resume path.
    This has been done for all arches barring blackfin, m68k* and xtensa, all of
    which need assembly alteration to support TIF_NOTIFY_RESUME. This allows the
    replacement to be performed at the point the parent process resumes userspace
    execution.

    This allows the userspace AFS pioctl emulation to fully emulate newpag() and
    the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
    alter the parent process's PAG membership. However, since kAFS doesn't use
    PAGs per se, but rather dumps the keys into the session keyring, the session
    keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
    the newpag flag.

    This can be tested with the following program:

    #include
    #include
    #include

    #define KEYCTL_SESSION_TO_PARENT 18

    #define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)

    int main(int argc, char **argv)
    {
    key_serial_t keyring, key;
    long ret;

    keyring = keyctl_join_session_keyring(argv[1]);
    OSERROR(keyring, "keyctl_join_session_keyring");

    key = add_key("user", "a", "b", 1, keyring);
    OSERROR(key, "add_key");

    ret = keyctl(KEYCTL_SESSION_TO_PARENT);
    OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");

    return 0;
    }

    Compiled and linked with -lkeyutils, you should see something like:

    [dhowells@andromeda ~]$ keyctl show
    Session Keyring
    -3 --alswrv 4043 4043 keyring: _ses
    355907932 --alswrv 4043 -1 \_ keyring: _uid.4043
    [dhowells@andromeda ~]$ /tmp/newpag
    [dhowells@andromeda ~]$ keyctl show
    Session Keyring
    -3 --alswrv 4043 4043 keyring: _ses
    1055658746 --alswrv 4043 4043 \_ user: a
    [dhowells@andromeda ~]$ /tmp/newpag hello
    [dhowells@andromeda ~]$ keyctl show
    Session Keyring
    -3 --alswrv 4043 4043 keyring: hello
    340417692 --alswrv 4043 4043 \_ user: a

    Where the test program creates a new session keyring, sticks a user key named
    'a' into it and then installs it on its parent.

    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     

19 Jun, 2009

2 commits

09 Jun, 2009

3 commits

04 Jun, 2009

1 commit

03 Jun, 2009

2 commits

02 Jun, 2009

2 commits

27 May, 2009

1 commit

  • b1338d199   tomoyo: add missing call to cap_bprm_set_creds ... Browse Code »

    cap_bprm_set_creds() has to be called from security_bprm_set_creds().
    TOMOYO forgot to call cap_bprm_set_creds() from tomoyo_bprm_set_creds()
    and suid executables were not being working.

    Make sure we call cap_bprm_set_creds() with TOMOYO, to set credentials
    properly inside tomoyo_bprm_set_creds().

    Signed-off-by: Herton Ronaldo Krzesinski
    Acked-by: Tetsuo Handa
    Signed-off-by: James Morris

    Herton Ronaldo Krzesinski
     

09 May, 2009

1 commit

14 Apr, 2009

1 commit

07 Apr, 2009

1 commit

01 Apr, 2009

1 commit

27 Mar, 2009

1 commit

23 Feb, 2009

1 commit

  • 1581e7ddb   TOMOYO: Do not call tomoyo_realpath_init unless registered. ... Browse Code »

    tomoyo_realpath_init() is unconditionally called by security_initcall().
    But nobody will use realpath related functions if TOMOYO is not registered.

    So, let tomoyo_init() call tomoyo_realpath_init().

    This patch saves 4KB of memory allocation if TOMOYO is not registered.

    Signed-off-by: Kentaro Takeda
    Signed-off-by: Tetsuo Handa
    Signed-off-by: Toshiharu Harada
    Signed-off-by: James Morris

    Tetsuo Handa
     

16 Feb, 2009

1 commit

14 Feb, 2009

1 commit

12 Feb, 2009

7 commits

  • 35d50e60e   tomoyo: fix sparse warning ... Browse Code »

    Fix sparse warning.

    $ make C=2 SUBDIRS=security/tomoyo CF="-D__cold__="
    CHECK security/tomoyo/common.c
    CHECK security/tomoyo/realpath.c
    CHECK security/tomoyo/tomoyo.c
    security/tomoyo/tomoyo.c:110:8: warning: symbol 'buf' shadows an earlier one
    security/tomoyo/tomoyo.c:100:7: originally declared here

    Signed-off-by: Kentaro Takeda
    Signed-off-by: Tetsuo Handa
    Signed-off-by: Toshiharu Harada
    Signed-off-by: James Morris

    Tetsuo Handa
     
  • 00d7d6f84   Kconfig and Makefile ... Browse Code »

    TOMOYO uses LSM hooks for pathname based access control and securityfs support.

    Signed-off-by: Kentaro Takeda
    Signed-off-by: Tetsuo Handa
    Signed-off-by: James Morris

    Kentaro Takeda
     
  • f74332437   LSM adapter functions. ... Browse Code »

    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
    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
    Signed-off-by: Tetsuo Handa
    Signed-off-by: Toshiharu Harada
    Signed-off-by: James Morris

    Kentaro Takeda
     
  • 26a2a1c9e   Domain transition handler. ... Browse Code »

    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 ' /sbin/init /etc/init.d/rc'.
    Domain information is stored in current->cred->security field.

    Signed-off-by: Kentaro Takeda
    Signed-off-by: Tetsuo Handa
    Signed-off-by: Toshiharu Harada
    Signed-off-by: James Morris

    Kentaro Takeda
     
  • b69a54ee5   File operation restriction part. ... Browse Code »

    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_".

    * 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
    Signed-off-by: Tetsuo Handa
    Signed-off-by: Toshiharu Harada
    Signed-off-by: James Morris

    Kentaro Takeda
     
  • 9590837b8   Common functions for TOMOYO Linux. ... Browse Code »

    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
    Signed-off-by: Tetsuo Handa
    Signed-off-by: Toshiharu Harada
    Signed-off-by: James Morris

    Kentaro Takeda
     
  • c73bd6d47   Memory and pathname management functions. ... Browse Code »

    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
    Signed-off-by: Tetsuo Handa
    Signed-off-by: Toshiharu Harada
    Signed-off-by: James Morris

    Kentaro Takeda