From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] pptp_t vs pppd_t
Date: Tue, 3 Jul 2012 17:20:29 +0200 [thread overview]
Message-ID: <20120703152029.GA22891@siphos.be> (raw)
In-Reply-To: <4FF2D4EE.6050805@redhat.com>
On Tue, Jul 03, 2012 at 07:18:06AM -0400, Daniel J Walsh wrote:
> I am always for merging domains together. I think we have far too many
> domains that basically have the security domain and just add complexity.
> Fedora consolidated all of the "spam" domains also.
>
> I really believe we should consolidate the mail domains. mail_t instead of
> sendmail_t, postfix_t, qmail_t, dovecot_t, courier_t ...
I disagree here. I'm not opposed to supporting consolidated domains, but I'd
rather support both. The policy language (refpolicy, that is) is flexible
enough to manage a mail domain that supports both a generic mail domain
as well as derived domains that inherit stuff from the mail domain (through
the use of a mail_domain_template).
My idea here is to have such generic domain modules, each with one, perhaps
two templates that allow policy developers to make more fine-grained
policies. The generic domain module (here "mailserver") would support generic
domains (like using mailserver_exec_t to transition to mailserver_t), but
also templates to either support a very strict set of privileges
("mailserver_strict_domain_template") or a more broader one
("mailserver_domain_template").
The broader one would probably be used for the "mailserver_t" domain, and
perhaps other multi-functional domains, whereas policy developers that want
a more strict approach use the mailserver_strict_domain_template to prepare
their domain (say sendmail_t) with those privileges that are common across
all mail servers, but nothing more.
The privileges you want to put in the mail domains would then be part of the
mailserver_domain_template. A subset of those privileges can be brought to
mailserver_strict_domain_template (like the corenet stuff for smtp ports).
That way, you can opt for the broader implementation, whereas others can use
a more strict configuration set.
Wkr,
Sven Vermeulen
prev parent reply other threads:[~2012-07-03 15:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 5:43 [refpolicy] pptp_t vs pppd_t Russell Coker
2012-07-03 11:18 ` Daniel J Walsh
2012-07-03 11:47 ` Miroslav Grepl
2012-07-03 11:55 ` Russell Coker
2012-07-03 13:44 ` Christopher J. PeBenito
2012-07-03 11:53 ` Russell Coker
2012-07-03 15:20 ` Sven Vermeulen [this message]
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=20120703152029.GA22891@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.