From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] ntp issue
Date: Mon, 13 Aug 2012 09:50:49 -0400 [thread overview]
Message-ID: <50290639.5090502@redhat.com> (raw)
In-Reply-To: <1344864696.11236.9.camel@d30.localdomain>
-----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-----
next prev parent reply other threads:[~2012-08-13 13:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-10 16:20 [refpolicy] ntp issue Dominick Grift
2012-08-10 16:59 ` Christopher J. PeBenito
2012-08-10 19:24 ` Guido Trentalancia
2012-08-13 13:27 ` Daniel J Walsh
2012-08-13 13:31 ` Dominick Grift
2012-08-13 13:50 ` Daniel J Walsh [this message]
2012-08-15 8:49 ` Guido Trentalancia
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=50290639.5090502@redhat.com \
--to=dwalsh@redhat.com \
--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.