[apparmor] AppArmor and ntpd

[John Johansen]

On 12/03/2010 10:26 AM, Steve Beattie wrote:
> On Fri, Dec 03, 2010 at 11:52:11AM -0600, Jamie Strandboge wrote:
>> On Fri, 2010-12-03 at 13:23 +0100, Martin Burnicki wrote:
>>> Hi all,
> 
> Hi Martin, welcome to the list. Thanks for raising the issue.
> 
>>> I've just subscribed to the list because of a bug report on openSUSE's
>>> bugzilla:
>>> https://bugzilla.novell.com/show_bug.cgi?id=230700
>>>
>>> I'd just like to bring to your mind (or remind you) that an NTP daemon
>>> running as stratum-1 time server usually needs to access a hardware
>>> device it uses as reference time source. If a refclock is connected via
>>> a serial port then the device node can be something like /dev/ttyS*, but
>>> there are also PCI cards which come with an own driver providing special
>>> device nodes to let ntpd read the ref time directly from the PCI card.
>>>
>>> For examples, the PCI cards manufactured by the company I'm working for
>>> come with a driver which implements device nodes /dev/mbgclock*.
>>>
>>> So It would be great if the names of such devices could easily be
>>> specified in an AppArmor profile for ntpd. AFAIK this is the case in the
>>> current implementation, but as said above, I just wanted to be sure this
>>> is kept in mind ... ;-)
>>
>> This sounds like a possible deficiency in the profile on OpenSUSE. The
>> AppArmor profile in trunk has:
>> #include <tunables/ntpd>
>> /usr/sbin/ntpd {
>> ...
>>   @{NTPD_DEVICE} rw,
>> ...
>>
>> This allows you to use /etc/apparmor.d/tunables/ntpd to adjust to the
>> device of your choosing.
> 
> Right, as was pointed out in
> https://bugzilla.novell.com/show_bug.cgi?id=230700#c12 To expand on
> the comment, though, the tunable variables can hold multiple values,
> such that defining:
> 
>   @{NTPD_DEVICE}="/dev/tty10" /dev/mbgclock* /dev/some_other_mfctr_devices*
> 
> will cause
> 
>   @{NTPD_DEVICE} rw,
> 
> to allow read and write access to all three sets of devices.
> 
> I think the important question that Martin is asking whether we
> think it's appropriate to include /dev/mbgclock* in the default
> tunable field in the distributed profile set. IMO, considering that
I think I'm okay with this as well

> it's a much more specialized device path than /dev/ttyS*, which the
> original referenced bugzilla report was asking about, I think it's
> a reasonable thing to include, as well as documentation explaining
> how to add additional devices to the tunable.

documentation is good but we really need a good way to make the
variables more visible and configurable