Comment on Do any hardened Linux distributions exist?

• ruination@discuss.tchncs.de ⁨1⁩ ⁨year⁩ ago

  What a coincidence, I’m trying to learn SELinux too! Any tips?

  source

  • ctr1@fl0w.cc ⁨1⁩ ⁨year⁩ ago

    Awesome! Here are a few things that come to mind:

    Make sure you have some aliases/functions for common operations:

    • audit2allow -a to view audit violations (or -d for dmesg audits)
      • also -r to add a requires statement for module construction
    • restorecon -Rv to recursively apply file contexts from policy (or -FRv to also apply user context)
    • rm -f /var/log/audit/audit.log.* && >/var/log/audit/audit.log to clear audit logs
      • note: sometimes lots of logfiles (audit.log.1, etc.) collect, slowing down audit2allow
    • chown -R user:user PATH && chcon -R -u user_u PATH to recursively change labels to user
      • could be generalized for arbitrary Linux/SELinux users
    • semanage fcontext -a -t $TYPE $PATH -s $SEUSER to add a custom file context to the policy
      • e.g. semanage fcontext -a -t “user_secrets_t” “/home/[^/]+/.secrets(/.*)?” -s user_u
      • I’ve had better luck with this approach than the standard method of creating a .fc file, but in any case a custom policy is needed to create custom types
    • semanage fcontext -d $PATH to remove a custom file context
    • semanage fcontext -lC to list custom file contexts
    • semodule -DB to rebuild policy with all dontaudit rules disabled
      • often, something will not work, but audit2allow doesn’t show anything
    • semodule -B to rebuild policy (with dontaudit rules)
    • semodule -i MODULE.pp to install a module
    • semodule -r MODULE to remove a module

    Also a few scripts for policy creation and management are essential. There are two basic approaches to policy creation:

    Modules: can be used to modify AVC rules and are pretty simple

    # a violation has occurred that you want to allow or dontaudit
    echo "module my_allow 1.0;" > my_allow.te
    audit2allow -ar >> my_allow.te
    
    # verify that my_allow.te has what you expect
    cat my_allow.te
    
    # build and install the module (replace mcs with whatever policy you are using)
    make -f /usr/share/selinux/mcs/include/Makefile my_allow.pp
    semodule -i my_allow.pp
    
    # clear audit logs
    rm -f /var/log/audit/audit.log.* && >/var/log/audit/audit.log
    

    Policy modules: can do anything, but are complicated, and the tools for creating them are mostly based on Red Hat.

    Creating a new type:

    # generate foo.fc, foo.if, and foo.te
    sepolicy generate --newtype -t foo_var_lib_t -n foo
    
    # note: see sepolicy-generate(8); sepolicy generate only supports the following
    #       type suffixes, but its output files can be adapted to your use case
    # _tmp_t
    # _unit_file_t
    # _var_cache_t
    # _var_lib_t
    # _var_log_t
    # _var_run_t
    # _var_spool_t
    # _port_t
    
    # modify the .fc file with the desired file contexts, for example (with s0 for mcs)
    # /path/to/context/target	--	gen_context(system_u:object_r:type_t,s0)
    #
    # note: the "--" matches regular files, -d for directories, -c for character
    #       devices, -l for symbolic links, -b for block devices, or can be omitted
    #       to match anything. also, as mentioned before, I often have better luck
    #       with `semanage fcontext`, especially for user directories
    vi foo.fc
    
    # build and install the policy module
    make -f /usr/share/selinux/mcs/include/Makefile foo.pp
    semodule -i foo.pp
    
    # use restorecon to adjust the file contexts of any paths you have 
    
    # by default, all operations involving this type will be denied
    # (and are sometimes not audited)
    semodule -DB # --disable_dontaudit
    # ... use the type, collect violations ...
    audit2allow -ar >> foo.te
    # if dontaudit is disabled, you'll likely have a lot things to remove from here
    vi foo.te
    
    # ... repeat until rules regarding type are fully defined
    

    Creating a new application type:

    # sepolicy-generate is made for Red Hat,
    # but you can use --application to get started
    
    # creates a bunch of files that define bar_t and bar_exec_t
    sepolicy generate --application -n bar [-u USER] CMD
    
    # remove the line making the app permissive (up to you, but
    # I prefer using audit violations to define the permissions)
    perl -i -00 -pe 's/^permissive bar_t;\n\n//g' bar.te
    
    # ensure that the file bar_exec_t file context points to the right bin:
    vi bar.fc
    
    # build and install the policy module
    make -f /usr/share/selinux/mcs/include/Makefile bar.pp
    semodule -i bar.pp
    
    # ... use the application, update AVC rules, repeat ...
    

    If your target application is interpreted, you’ll need to write a custom C program that launches the interpreter in a specific context, then write your policy around that application. For example, you should execv something like this: /usr/bin/runcon -u user_u -t my_script_t /bin/bash PROG.

    source

    • ruination@discuss.tchncs.de ⁨1⁩ ⁨year⁩ ago

      Thanks! I’ll be copypasting all of these to my notes haha

      source

      • ctr1@fl0w.cc ⁨1⁩ ⁨year⁩ ago

        np! Hope it helps; it’s a big pain but I do think it’s pretty secure if configured correctly

        source