[refpolicy] pptp_t vs pppd_t

[refpolicy] pptp_t vs pppd_t

[Russell Coker]

Is there a real benefit in having separate domains for pptp and pppd?

The access that they have is very similar and the differences are things that 
aren't so significant (EG pptp_t denied access to pppd_devpts_t:chr_file).

Also both the programs can run each other (the policy allows pppd to run pptpd 
and in my test network pptpd needs to run pppd) which limits the ability to 
create a useful separation.

I think it would be best if we merged the two domains.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] pptp_t vs pppd_t

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/2012 01:43 AM, Russell Coker wrote:
> Is there a real benefit in having separate domains for pptp and pppd?
> 
> The access that they have is very similar and the differences are things
> that aren't so significant (EG pptp_t denied access to
> pppd_devpts_t:chr_file).
> 
> Also both the programs can run each other (the policy allows pppd to run
> pptpd and in my test network pptpd needs to run pppd) which limits the
> ability to create a useful separation.
> 
> I think it would be best if we merged the two domains.
> 

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 ...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/y1O4ACgkQrlYvE4MpobPtpgCgpl0i5SgNbakzYEOO8V0tDvAN
lTYAoNVw17S4dCdmCdbfqFD1zUjEfPo9
=qWw4
-----END PGP SIGNATURE-----

[refpolicy] pptp_t vs pppd_t

[Miroslav Grepl]

On 07/03/2012 01:18 PM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/03/2012 01:43 AM, Russell Coker wrote:
>> Is there a real benefit in having separate domains for pptp and pppd?
>>
>> The access that they have is very similar and the differences are things
>> that aren't so significant (EG pptp_t denied access to
>> pppd_devpts_t:chr_file).
>>
>> Also both the programs can run each other (the policy allows pppd to run
>> pptpd and in my test network pptpd needs to run pppd) which limits the
>> ability to create a useful separation.
>>
>> I think it would be best if we merged the two domains.
>>
> 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 agree with this. The question is whether it could be accepted?
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/y1O4ACgkQrlYvE4MpobPtpgCgpl0i5SgNbakzYEOO8V0tDvAN
> lTYAoNVw17S4dCdmCdbfqFD1zUjEfPo9
> =qWw4
> -----END PGP SIGNATURE-----
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] pptp_t vs pppd_t

[Russell Coker]

On Tue, 3 Jul 2012, Miroslav Grepl <mgrepl@redhat.com> wrote:
> > I really believe we should consolidate the mail domains.  mail_t instead
> > of sendmail_t, postfix_t, qmail_t, dovecot_t, courier_t ...
> 
> I agree with this. The question is whether it could be accepted?

Red Hat had a 152,000 line patch against the policy source last time I 
checked.  It doesn't seem that patch acceptance or the lack of it is slowing 
them down.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] pptp_t vs pppd_t

[Christopher J. PeBenito]

On 7/3/2012 7:47 AM, Miroslav Grepl wrote:
> On 07/03/2012 01:18 PM, Daniel J Walsh wrote:
>> On 07/03/2012 01:43 AM, Russell Coker wrote:
>>> Is there a real benefit in having separate domains for pptp and pppd?
>>>
>>> The access that they have is very similar and the differences are things
>>> that aren't so significant (EG pptp_t denied access to
>>> pppd_devpts_t:chr_file).
>>>
>>> Also both the programs can run each other (the policy allows pppd to run
>>> pptpd and in my test network pptpd needs to run pppd) which limits the
>>> ability to create a useful separation.
>>>
>>> I think it would be best if we merged the two domains.
>>>
>> 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 agree with this. The question is whether it could be accepted?

Dan has contrib commit access, so he can upstream the changes.  I'm fine with the pptp/pppd merging. (don't forget aliases, etc. for compatibility)  The mail server domains is a little dicier, as that is a significant change, and my preference would be to discuss what can be done, as I generally agree with Russell's other email.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] pptp_t vs pppd_t

[Russell Coker]

On Tue, 3 Jul 2012, Daniel J Walsh <dwalsh@redhat.com> wrote:
> I really believe we should consolidate the mail domains.  mail_t instead of
> sendmail_t, postfix_t, qmail_t, dovecot_t, courier_t ...

Sendmail works differently from all the modern MTAs in terms of separating 
different tasks to run with minimum privs.

For postfix and similar MTAs it's best to have separate privs for the local 
delivery agent which is granted a lot of access to the system (writing to user 
home directories) and also having a separate domain for writing to the queue 
dir that can't do anything else is also a good idea.

dovecot_t and courier_t are used for POP and IMAP, we could have an imap_t 
instead as in the rare cases where someone has two different POP or IMAP 
servers installed on one system they probably don't need to separate them.  
But the POP/IMAP server really needs to be separated from the MTA.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] pptp_t vs pppd_t

[Sven Vermeulen]

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