10 Apr, 2012

1 commit

  • When new objects are created we have great and flexible rules to
    determine the type of the new object. We aren't quite as flexible or
    mature when it comes to determining the user, role, and range. This
    patch adds a new ability to specify the place a new objects user, role,
    and range should come from. For users and roles it can come from either
    the source or the target of the operation. aka for files the user can
    either come from the source (the running process and todays default) or
    it can come from the target (aka the parent directory of the new file)

    examples always are done with
    directory context: system_u:object_r:mnt_t:s0-s0:c0.c512
    process context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    [no rule]
    unconfined_u:object_r:mnt_t:s0 test_none
    [default user source]
    unconfined_u:object_r:mnt_t:s0 test_user_source
    [default user target]
    system_u:object_r:mnt_t:s0 test_user_target
    [default role source]
    unconfined_u:unconfined_r:mnt_t:s0 test_role_source
    [default role target]
    unconfined_u:object_r:mnt_t:s0 test_role_target
    [default range source low]
    unconfined_u:object_r:mnt_t:s0 test_range_source_low
    [default range source high]
    unconfined_u:object_r:mnt_t:s0:c0.c1023 test_range_source_high
    [default range source low-high]
    unconfined_u:object_r:mnt_t:s0-s0:c0.c1023 test_range_source_low-high
    [default range target low]
    unconfined_u:object_r:mnt_t:s0 test_range_target_low
    [default range target high]
    unconfined_u:object_r:mnt_t:s0:c0.c512 test_range_target_high
    [default range target low-high]
    unconfined_u:object_r:mnt_t:s0-s0:c0.c512 test_range_target_low-high

    Signed-off-by: Eric Paris

    Eric Paris
     

04 Feb, 2010

1 commit


05 Jan, 2009

1 commit

  • 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
    Signed-off-by: James Morris

    Eric Paris
     

14 Jul, 2008

1 commit

  • Introduce SELinux support for deferred mapping of security contexts in
    the SID table upon policy reload, and use this support for inode
    security contexts when the context is not yet valid under the current
    policy. Only processes with CAP_MAC_ADMIN + mac_admin permission in
    policy can set undefined security contexts on inodes. Inodes with
    such undefined contexts are treated as having the unlabeled context
    until the context becomes valid upon a policy reload that defines the
    context. Context invalidation upon policy reload also uses this
    support to save the context information in the SID table and later
    recover it upon a subsequent policy reload that defines the context
    again.

    This support is to enable package managers and similar programs to set
    down file contexts unknown to the system policy at the time the file
    is created in order to better support placing loadable policy modules
    in packages and to support build systems that need to create images of
    different distro releases with different policies w/o requiring all of
    the contexts to be defined or legal in the build host policy.

    With this patch applied, the following sequence is possible, although
    in practice it is recommended that this permission only be allowed to
    specific program domains such as the package manager.

    # rmdir baz
    # rm bar
    # touch bar
    # chcon -t foo_exec_t bar # foo_exec_t is not yet defined
    chcon: failed to change context of `bar' to `system_u:object_r:foo_exec_t': Invalid argument
    # mkdir -Z system_u:object_r:foo_exec_t baz
    mkdir: failed to set default file creation context to `system_u:object_r:foo_exec_t': Invalid argument
    # cat setundefined.te
    policy_module(setundefined, 1.0)
    require {
    type unconfined_t;
    type unlabeled_t;
    }
    files_type(unlabeled_t)
    allow unconfined_t self:capability2 mac_admin;
    # make -f /usr/share/selinux/devel/Makefile setundefined.pp
    # semodule -i setundefined.pp
    # chcon -t foo_exec_t bar # foo_exec_t is not yet defined
    # mkdir -Z system_u:object_r:foo_exec_t baz
    # ls -Zd bar baz
    -rw-r--r-- root root system_u:object_r:unlabeled_t bar
    drwxr-xr-x root root system_u:object_r:unlabeled_t baz
    # cat foo.te
    policy_module(foo, 1.0)
    type foo_exec_t;
    files_type(foo_exec_t)
    # make -f /usr/share/selinux/devel/Makefile foo.pp
    # semodule -i foo.pp # defines foo_exec_t
    # ls -Zd bar baz
    -rw-r--r-- root root user_u:object_r:foo_exec_t bar
    drwxr-xr-x root root system_u:object_r:foo_exec_t baz
    # semodule -r foo
    # ls -Zd bar baz
    -rw-r--r-- root root system_u:object_r:unlabeled_t bar
    drwxr-xr-x root root system_u:object_r:unlabeled_t baz
    # semodule -i foo.pp
    # ls -Zd bar baz
    -rw-r--r-- root root user_u:object_r:foo_exec_t bar
    drwxr-xr-x root root system_u:object_r:foo_exec_t baz
    # semodule -r setundefined foo
    # chcon -t foo_exec_t bar # no longer defined and not allowed
    chcon: failed to change context of `bar' to `system_u:object_r:foo_exec_t': Invalid argument
    # rmdir baz
    # mkdir -Z system_u:object_r:foo_exec_t baz
    mkdir: failed to set default file creation context to `system_u:object_r:foo_exec_t': Invalid argument

    Signed-off-by: Stephen Smalley
    Signed-off-by: James Morris

    Stephen Smalley
     

28 Apr, 2008

1 commit


09 Jan, 2007

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds