From: nicolas.iooss@m4x.org (Nicolas Iooss)
Date: Sun, 19 Feb 2017 22:38:33 +0100
Subject: [refpolicy] [PATCH] another first systemd patch
In-Reply-To: <20170219114926.ji3zbisfqbhy7lk5@athena.coker.com.au>
References: <20170219114926.ji3zbisfqbhy7lk5@athena.coker.com.au>
Message-ID: <CAJfZ7==cmWTypA5+9wRX5N4mHB-YAVTttm-H3pg6Ch4JDpOkiQ@mail.gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Sun, Feb 19, 2017 at 12:49 PM, Russell Coker via refpolicy <
refpolicy@oss.tresys.com> wrote:

> Here's another first patch for systemd support.  I split out the misc patch
> and parts of what became the dpkg patch as well as a heap of other stuff
> that
> will be in a later patch.
>
> This patch has all the interfaces needed to build and no excess interfaces.
>
> It starts with allowing a dynamic transition from kernel_t which is
> something
> that systemd likes to do.  It has lots of changes for init_t which are
> needed
> by systemd which does a lot more than the old SysV init.
>
> It probably also has some init_t and initrc_t changes that aren't specific
> to
> systemd.  As I only use systemd I don't know exactly what is required
> without
> it nowadays.
>
> The file contexts have a few non-systemd changes that were in the same
> patch,
> while I'm aiming to just have systemd stuff sometimes it seems easier to
> put
> a few little things in than to split them out.
>
> There are significant changes to syslogd_t because we have systemd-journald
> running in that domain and it does a lot more.
>
> There are some changes to userdomain policy to interact with systemd.  The
> way systemd manages logins requires a lot more interaction with various
> daemons.
>
> There's a minor change to the lvm related policy due to having a systemd
> process using that domain.  lvm_t isn't an ideal name any more, but that's
> an
> issue to discuss later.
>
> For the main systemd policy I only added some extra type definitions and
> the
> policy for systemd_backlight_t.  I added policy for systemd_backlight_t
> instead of any of the other systemd domains because I have the policy
> file in alphabetical order and I didn't want to make a huge patch.  There
> is more to come in future patches.  ;)
>
> [...]

> @@ -140,29 +176,33 @@ dontaudit systemd_log_parse_env_type sel
>  kernel_read_system_state(systemd_log_parse_env_type)
>
>  dev_write_kmsg(systemd_log_parse_env_type)
> -
> -term_use_console(systemd_log_parse_env_type)
> -
>  init_read_state(systemd_log_parse_env_type)
> -
>  logging_send_syslog_msg(systemd_log_parse_env_type)
> +term_use_console(systemd_log_parse_env_type)
>
>  ######################################
>  #
>  # Backlight local policy
>  #
>
> +allow systemd_backlight_t self:unix_dgram_socket { connect
> connected_socket_perms };
> +
>  allow systemd_backlight_t systemd_backlight_var_lib_t:dir
> manage_dir_perms;
> -init_var_lib_filetrans(systemd_backlight_t, systemd_backlight_var_lib_t,
> dir)
>  manage_files_pattern(systemd_backlight_t, systemd_backlight_var_lib_t,
> systemd_backlight_var_lib_t)
> -
>  systemd_log_parse_environment(systemd_backlight_t)
>
> +kernel_read_system_state(systemd_backlight_t)
> +
>  # Allow systemd-backlight to write to /sys/class/backlight/*/brightness
>  dev_rw_sysfs(systemd_backlight_t)
> -
> +dev_write_kmsg(systemd_backlight_t)
> +# for udev.conf
>  files_read_etc_files(systemd_backlight_t)
>
> +init_read_state(systemd_backlight_t)
> +init_var_lib_filetrans(systemd_backlight_t, systemd_backlight_var_lib_t,
> dir)
> +logging_send_syslog_msg(systemd_backlight_t)
> +# for /run/udev/data/+backlight*
>  udev_read_pid_files(systemd_backlight_t)
>

Why are init_read_state(systemd_backlight_t),
logging_send_syslog_msg(systemd_backlight_t)...
needed with systemd_log_parse_environment(systemd_backlight_t)? The
accesses these calls provide should already be handled by attribute
systemd_log_parse_env_type, right above in systemd.te.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20170219/e1421379/attachment-0001.html