[pkg-apparmor] [PATCH 2/6] Add a profile for ntpd.

[Felix Geyer]

Hi,

On 30.08.2014 22:53, intrigeri wrote:
> Hi,
> 
> Felix Geyer wrote (30 Aug 2014 19:04:48 GMT) :
>> On 30.08.2014 20:42, intrigeri wrote:
>>> However, this profile may not be loaded soon enough to be actually
>>> applied, see Debian#670170 -- Ubuntu does that with upstart, and we
>>> don't have the corresponding systemd bits in sid yet.
> 
>> Ubuntu only has that problem because it's using an upstart job instead
>> of the init script.
> 
> Ah, I was confusing this situation with the dhclient one (where the
> profile must be loaded before any network interface is up'ed, which
> can't be guaranteed as long as we use an apparmor initscript that is
> started after $remote_fs).
> 
> Not that it matters much, but I don't think Ubuntu is using an upstart
> job for ntp. My understanding is that when before the network is
> up'ed, apparmor_parser is run against the profiles linked from
> /etc/apparmor/init/network-interface-security. So, in the case of ntp,
> this merely adds a safeguard, just in case something starts the
> network before the apparmor initscript has run, somehow. I think :)

Ah right, there is no upstart job but Ubuntu ships a modified version of
/etc/network/if-up.d/ntpdate.
It stops and starts ntp which likely causes it to start earlier.

>>> Did you try how it goes on current Debian sid, in practice? I'd love
>>> to see a test matrix for (server, desktop) x (sysvinit, systemd).
> 
>> I tested it with systemd. I don't think server / desktop makes a difference.
>> The apparmor init script is started in runlevel S. I think even with
>> systemd that's guaranteed to be started before the usual runlevel 2-5 init
>> scripts.
> 
> Yep, and I've verified it's the case thanks to systemctl
> list-dependencies. I've also verified (by testing try-restart
> manually) that /etc/dhcp/dhclient-exit-hooks.d/ntp doesn't start the
> ntp service if it's not running yet. So, we should be fine for now.
> 
>> However when ntp gains a systemd service file this might become a problem.
> 
> Right. Once it happens, the ntp unit file will likely need something
> similar to what libvirtd.service has: After=apparmor.service
> ... although ideally, this would be automated in some way.

For libvirtd.service this isn't necessary is it?

I've looked some more at the systemd service dependencies.
All services that don't have DefaultDependencies=no should be fine since
apparmor.service is ordered before basic.target (through sysinit.target).

We could probably add the same hack as Ubuntu to load some profiles before the
network is up.

>> I've heard there are plans to rewrite the AppArmor parser as a library so it
>> can be used by systemd to load profiles. I suspect that will take some
>> time however.
> 
> I guess so. Any idea what Ubuntu release it's a goal for?

Sorry, no idea.

Cheers,
Felix