[refpolicy] pptp_t vs pppd_t

Sven Vermeulen sven.vermeulen at siphos.be
Tue Jul 3 10:20:29 CDT 2012

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

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.

	Sven Vermeulen

More information about the refpolicy mailing list