From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH 1/3] Introduce vde domain
Date: Fri, 11 Nov 2011 19:37:51 +0100 [thread overview]
Message-ID: <20111111183751.GA8548@siphos.be> (raw)
In-Reply-To: <4EB94452.9010009@tresys.com>
On Tue, Nov 08, 2011 at 10:01:38AM -0500, Christopher J. PeBenito wrote:
> > + tunable_policy(`gentoo_try_dontaudit',`
> > + dontaudit $1 vde_var_run_t:sock_file { setattr };
> > + ')
>
> Remember to remove these testing rules. Its also unnecessary to have the braces for single permissions.
Yeah, sorry about that.
> > +allow vde_t self:process { signal_perms getcap setcap };
> > +allow vde_t self:capability { chown net_admin dac_override fowner fsetid };
> > +allow vde_t self:unix_stream_socket { create_stream_socket_perms connectto };
> > +allow vde_t self:unix_dgram_socket create_socket_perms;
> > +allow vde_t vde_conf_t:dir list_dir_perms;
> > +allow vde_t vde_tmp_t:sock_file manage_sock_file_perms;
>
> Please move these down with the other rules.
You mean keep the "allow" statements with the general patterns? Like so?
allow vde_t self:process { signal_perms getcap setcap };
allow vde_t self:capability { chown net_admin dac_override fowner fsetid };
allow vde_t self:unix_stream_socket { create_stream_socket_perms connectto };
allow vde_t self:unix_dgram_socket create_socket_perms;
manage_dirs_pattern(vde_t, vde_var_run_t, vde_var_run_t)
manage_files_pattern(vde_t, vde_var_run_t, vde_var_run_t)
manage_sock_files_pattern(vde_t, vde_var_run_t, vde_var_run_t)
files_pid_filetrans(vde_t, vde_var_run_t, { dir file sock_file unix_dgram_socket })
allow vde_t vde_tmp_t:sock_file manage_sock_file_perms;
files_tmp_filetrans(vde_t, vde_tmp_t, sock_file)
Is it okay to have a whitespace between allow blocks and other (general
pattern) blocks?
> I'm not clear why there is a need for vde_conf_t. It appears that it is only
> ever read, so it seems that etc_t would be fine.
True. I had defined it to allow for third party applications to manage it,
but it seems that those that I expect to manage them also have etc_t write
privileges already (like puppet).
I'll remove it from the renewed submission.
Wkr,
Sven Vermeulen
next prev parent reply other threads:[~2011-11-11 18:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-23 14:07 [refpolicy] [PATCH 0/3] Virtual Distributed Ethernet Sven Vermeulen
2011-10-23 14:08 ` [refpolicy] [PATCH 1/3] Introduce vde domain Sven Vermeulen
2011-11-08 15:01 ` Christopher J. PeBenito
2011-11-11 18:37 ` Sven Vermeulen [this message]
2011-10-23 14:08 ` [refpolicy] [PATCH 2/3] Allow qemu to interact with VDE Sven Vermeulen
2011-10-23 14:09 ` [refpolicy] [PATCH 3/3] Allow sysadm_r to manage vde switches Sven Vermeulen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111111183751.GA8548@siphos.be \
--to=sven.vermeulen@siphos.be \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.