2012-08-10 16:20:11

by dominick.grift

[permalink] [raw]
Subject: [refpolicy] ntp issue

I was playing with ntp_admin() and i figured out that /etc/ntp.conf is
labeled net_conf_t. What is the rationale behind that decision, I dont
see it?

Whatever the reason for this is, its not implemented properly. The
net_conf_t type should not be used in the ntp.fc file.

Instead, if one really wants /etc/ntp.conf to be net_conf_t, then move
the fc spec to sysnetwork.fc

But again i dont see why this file has to be net_conf_t. Its not good
for ntp_admin either. I wouldnt want my ntp_admin to have access to
net_conf_t files just so that he is able to manage ntp config files


2012-08-10 16:59:07

by cpebenito

[permalink] [raw]
Subject: [refpolicy] ntp issue

On 08/10/12 12:20, Dominick Grift wrote:
> I was playing with ntp_admin() and i figured out that /etc/ntp.conf is
> labeled net_conf_t. What is the rationale behind that decision, I dont
> see it?

I'd say its a mistake.

> Whatever the reason for this is, its not implemented properly. The
> net_conf_t type should not be used in the ntp.fc file.
>
> Instead, if one really wants /etc/ntp.conf to be net_conf_t, then move
> the fc spec to sysnetwork.fc
>
> But again i dont see why this file has to be net_conf_t. Its not good
> for ntp_admin either. I wouldnt want my ntp_admin to have access to
> net_conf_t files just so that he is able to manage ntp config files

I'm fine with a patch that makes a ntp_conf_t.

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

2012-08-10 19:24:55

by Guido Trentalancia

[permalink] [raw]
Subject: [refpolicy] ntp issue

On 10/08/2012 18:20, Dominick Grift wrote:
> I was playing with ntp_admin() and i figured out that /etc/ntp.conf is
> labeled net_conf_t. What is the rationale behind that decision, I dont
> see it?

If net_conf_t is also used in ntp.te then it sounds like a security flaw.

Otherwise, it's a typo, which however might not be unlikely to lead to a
security flaw in the future.

> Whatever the reason for this is, its not implemented properly. The
> net_conf_t type should not be used in the ntp.fc file.

> Instead, if one really wants /etc/ntp.conf to be net_conf_t, then move
> the fc spec to sysnetwork.fc

There should be its own type.

> But again i dont see why this file has to be net_conf_t. Its not good
> for ntp_admin either. I wouldnt want my ntp_admin to have access to
> net_conf_t files just so that he is able to manage ntp config files

Regards,

Guido

2012-08-13 13:27:43

by Daniel Walsh

[permalink] [raw]
Subject: [refpolicy] ntp issue

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

On 08/10/2012 03:24 PM, Guido Trentalancia wrote:
> On 10/08/2012 18:20, Dominick Grift wrote:
>> I was playing with ntp_admin() and i figured out that /etc/ntp.conf is
>> labeled net_conf_t. What is the rationale behind that decision, I dont
>> see it?
>
> If net_conf_t is also used in ntp.te then it sounds like a security flaw.
>
> Otherwise, it's a typo, which however might not be unlikely to lead to a
> security flaw in the future.
>
>> Whatever the reason for this is, its not implemented properly. The
>> net_conf_t type should not be used in the ntp.fc file.
>
>> Instead, if one really wants /etc/ntp.conf to be net_conf_t, then move
>> the fc spec to sysnetwork.fc
>
> There should be its own type.
>
>> But again i dont see why this file has to be net_conf_t. Its not good for
>> ntp_admin either. I wouldnt want my ntp_admin to have access to
>> net_conf_t files just so that he is able to manage ntp config files
>
> Regards,
>
> Guido _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>

I agree it should not be net_conf_t, but I think we will need to make sure
that NetworkManager_t can configure it, as it was most likely changed to this
label when a network configuration tool needed to manage it. Now that we have
filename transition rules we can label /etc/resolv.conf and /etc/ntp.conf
differently and allow network manage ment tools to manage and maintain the labels.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlApAM8ACgkQrlYvE4MpobOgaQCg69H6oJeitKhiw+K/n3oL39iO
f6cAoKFcmSXEJKL4GUF1DL59XmIXHUs3
=GaiW
-----END PGP SIGNATURE-----

2012-08-13 13:31:36

by dominick.grift

[permalink] [raw]
Subject: [refpolicy] ntp issue



On Mon, 2012-08-13 at 09:27 -0400, Daniel J Walsh wrote:
> On 08/10/2012 03:24 PM, Guido Trentalancia wrote:
> > On 10/08/2012 18:20, Dominick Grift wrote:
> >> I was playing with ntp_admin() and i figured out that /etc/ntp.conf is
> >> labeled net_conf_t. What is the rationale behind that decision, I dont
> >> see it?
> >
> > If net_conf_t is also used in ntp.te then it sounds like a security flaw.
> >
> > Otherwise, it's a typo, which however might not be unlikely to lead to a
> > security flaw in the future.
> >
> >> Whatever the reason for this is, its not implemented properly. The
> >> net_conf_t type should not be used in the ntp.fc file.
> >
> >> Instead, if one really wants /etc/ntp.conf to be net_conf_t, then move
> >> the fc spec to sysnetwork.fc
> >
> > There should be its own type.
> >
> >> But again i dont see why this file has to be net_conf_t. Its not good for
> >> ntp_admin either. I wouldnt want my ntp_admin to have access to
> >> net_conf_t files just so that he is able to manage ntp config files
> >
> > Regards,
> >
> > Guido _______________________________________________ refpolicy mailing
> > list refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> >
>
> I agree it should not be net_conf_t, but I think we will need to make sure
> that NetworkManager_t can configure it, as it was most likely changed to this
> label when a network configuration tool needed to manage it. Now that we have
> filename transition rules we can label /etc/resolv.conf and /etc/ntp.conf
> differently and allow network manage ment tools to manage and maintain the labels.

That is what i thought as well but git blame shows otherwise. This has
been there ever since the first iteration of this module.

2012-08-13 13:50:49

by Daniel Walsh

[permalink] [raw]
Subject: [refpolicy] ntp issue

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

On 08/13/2012 09:31 AM, Dominick Grift wrote:
>
>
> On Mon, 2012-08-13 at 09:27 -0400, Daniel J Walsh wrote:
>> On 08/10/2012 03:24 PM, Guido Trentalancia wrote:
>>> On 10/08/2012 18:20, Dominick Grift wrote:
>>>> I was playing with ntp_admin() and i figured out that /etc/ntp.conf
>>>> is labeled net_conf_t. What is the rationale behind that decision, I
>>>> dont see it?
>>>
>>> If net_conf_t is also used in ntp.te then it sounds like a security
>>> flaw.
>>>
>>> Otherwise, it's a typo, which however might not be unlikely to lead to
>>> a security flaw in the future.
>>>
>>>> Whatever the reason for this is, its not implemented properly. The
>>>> net_conf_t type should not be used in the ntp.fc file.
>>>
>>>> Instead, if one really wants /etc/ntp.conf to be net_conf_t, then
>>>> move the fc spec to sysnetwork.fc
>>>
>>> There should be its own type.
>>>
>>>> But again i dont see why this file has to be net_conf_t. Its not good
>>>> for ntp_admin either. I wouldnt want my ntp_admin to have access to
>>>> net_conf_t files just so that he is able to manage ntp config files
>>>
>>> Regards,
>>>
>>> Guido _______________________________________________ refpolicy
>>> mailing list refpolicy at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>
>>
>> I agree it should not be net_conf_t, but I think we will need to make
>> sure that NetworkManager_t can configure it, as it was most likely
>> changed to this label when a network configuration tool needed to manage
>> it. Now that we have filename transition rules we can label
>> /etc/resolv.conf and /etc/ntp.conf differently and allow network manage
>> ment tools to manage and maintain the labels.
>
> That is what i thought as well but git blame shows otherwise. This has been
> there ever since the first iteration of this module.
>
>
Ok. Lets try it out and see if NetworkManager starts to complain...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlApBjkACgkQrlYvE4MpobOeRQCg0D30zUW1QA9fdiJ0Umkbgoi9
PyEAnjLB7N3Wvup1CWUgariyzUiD632q
=kkPV
-----END PGP SIGNATURE-----

2012-08-15 08:49:27

by Guido Trentalancia

[permalink] [raw]
Subject: [refpolicy] ntp issue

On 13/08/2012 15:27, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/10/2012 03:24 PM, Guido Trentalancia wrote:
>> On 10/08/2012 18:20, Dominick Grift wrote:
>>> I was playing with ntp_admin() and i figured out that /etc/ntp.conf is
>>> labeled net_conf_t. What is the rationale behind that decision, I dont
>>> see it?
>>
>> If net_conf_t is also used in ntp.te then it sounds like a security flaw.
>>
>> Otherwise, it's a typo, which however might not be unlikely to lead to a
>> security flaw in the future.
>>
>>> Whatever the reason for this is, its not implemented properly. The
>>> net_conf_t type should not be used in the ntp.fc file.
>>
>>> Instead, if one really wants /etc/ntp.conf to be net_conf_t, then move
>>> the fc spec to sysnetwork.fc
>>
>> There should be its own type.
>>
>>> But again i dont see why this file has to be net_conf_t. Its not good for
>>> ntp_admin either. I wouldnt want my ntp_admin to have access to
>>> net_conf_t files just so that he is able to manage ntp config files
>>
>> Regards,
>>
>> Guido

> I agree it should not be net_conf_t, but I think we will need to make sure
> that NetworkManager_t can configure it, as it was most likely changed to this
> label when a network configuration tool needed to manage it. Now that we have
> filename transition rules we can label /etc/resolv.conf and /etc/ntp.conf
> differently and allow network manage ment tools to manage and maintain the labels.

In my opinion, this is a good point, but it's only really needed in
certain conditions (multiuser X mode). So, definitely, not on servers
running at init level 3 or, say, kiosks running single-mode.

Ideally, tunable policy should be used to restore the above
compatibility with NetworkManager on the desktops (and maybe those
servers) that actually use it.

On Fedora, you could then even toggle such boolean on/off upon
installation/removal of the NM package (%postinstall, %preinstall spec
sections).

But having a stricter policy for safer servers should probably be the
priority in my opinion.

Regards,

Guido