[apparmor] AppArmor and ntpd

[John Johansen]

On 12/06/2010 08:38 AM, Martin Burnicki wrote:
> Steve Beattie wrote:
> [...]
>> 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.
> 
> That's an interesting way to get this working.
> 
>> 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.
> 
> I've not really been asking to include /dev/mbgclock* as a default. Just
> wanted to be sure it can easily be added. Anyway, if it can become one
> of the defaults it's even better.
> 
>> IMO, considering that
>> 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.
>>
>> As an aside, looking at what our existing ntpd tunable has, we already
>> allow /dev/tty10. It looks like it got added in response to novell
>> bugzilla bugs 433368 or 402693, which I'm not privileged enough
>> to view.  Christian, do you have access to those bugs to clarify the
>> justification for it? I really don't like it as a default, though I'll
>> admit it's far less likely that /dev/tty10 will be used by anything
>> else, unlike /dev/ttyS*.
> 
> I also find it strange to include one single dedicated serial port as
> default.
> 
> Maybe it could be better to use /dev/refclock-* as a default. These are
> usually symlinks used by ntpd's parse driver which point to real
> /dev/ttyS* devices, if used by ntpd, and even if /dev/mbgclock* is used
> by ntpd it is accesssed via a /dev/refclock-* symlink.
> 
Well the symlink is actually problematic, in that apparmor's rules and
mediation are post symlink resolution.

You could add an alias rule, but in this case that is not really any
better than the variable, as you have to know what the target of the
symlink is.