Managing time, date and timezone in Ubuntu Core

jdstrand · July 6, 2017, 5:51pm

Looking at the timeserver-control interface, it allows timedatectl and various DBus APIs for using set-ntp, so yes, it is supposed to work.

jenny.murphy · July 18, 2017, 8:46am

I have now snapd 2.26.0 and can use timedatectl.

I still get the following denials reported through snappy-debug:

= AppArmor = Time: Jul 18 08:37:31 Log: apparmor=“ALLOWED” operation=“open” profile=“snap.epi-gateway.main” name=“/proc/1/environ” pid=5644 comm=“timedatectl.rea” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0 File: /proc/1/environ (read) Suggestion:

adjust program to not access ‘@{PROC}/@{pid}/environ’

= AppArmor = Time: Jul 18 08:37:31 Log: apparmor=“ALLOWED” operation=“ptrace” profile=“snap.epi-gateway.main” pid=5644 comm=“timedatectl.rea” requested_mask=“trace” denied_mask=“trace” peer=“unconfined”

The second one probably is ok, What about the first one?

niemeyer · August 8, 2017, 6:21pm

@jenny.murphy Did you manage to address your problem there? The process is trying to read the environment of the init process in the system, which is a bit of a strange thing to do. Do you have more details?

jenny.murphy · August 21, 2017, 10:45am

Hi, Yes I still get the same denial.

I am using timedatectl for setting time, timezone and also switching off/ on NTP so for example I am effectively invoking

timedatectl set-ntp true

from my Java process.

What other information could I provide that would be of use?

zyga-snapd · August 21, 2017, 11:07am

Sorry for the lag, I didn’t notice the @-mention. The packaging for Fedora has landed and 2.27.x is about to be released into the stable channel.

jenny.murphy · August 21, 2017, 11:18am

@zyga-snapd Do you think the denial I have will be fixed in this new version?

zyga-snapd · August 21, 2017, 11:21am

The only mention of /proc/.../environ that I can see is in the greengrass support interface. CCing @jdstrand – my guesstimate says “no”.

jenny.murphy · November 1, 2017, 9:59am

I checked the status of this with the latest version from the stable channel.

admin@1TXPB02:~$ snap list
Name Version Rev Developer Notes
core 16-2.28.5 3247 canonical core

Still getting following denials :

= AppArmor =
Time: Nov 1 09:36:02
Log: apparmor=“ALLOWED” operation=“open” profile=“snap.epi-gateway.main” name="/proc/1/environ" pid=9069 comm=“timedatectl.rea” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /proc/1/environ (read)
Suggestion:
* adjust program to not access ‘@{PROC}/@{pid}/environ’

= AppArmor =
Time: Nov 1 09:36:02
Log: apparmor=“ALLOWED” operation=“ptrace” profile=“snap.epi-gateway.main” pid=9069 comm=“timedatectl.rea” requested_mask=“trace” denied_mask=“trace” peer=“unconfined”
Ptrace: peer=unconfined (trace)
Suggestions:
* adjust program to not trace processes
* do nothing if program otherwise works properly

Why is invoking timedatectl from the program resulting in the first one?

Is it still ok to get the second one?

jdstrand · November 1, 2017, 2:25pm

There are no interfaces to allow the second denial (it would allow breaking out of confinement). systemd itself is not designed for application isolation and it will try to interact with its processes in various ways.

We could allow this rule though: @{PROC}/1/environ r, (there isn’t anything sensitive in there), but I don’t see either denial on a Ubuntu 16.04 LTS classic or an Ubuntu Core 16 system. I tried various timedatectl invocations. How are you calling it?

ogra · November 1, 2017, 2:32pm

note that the timedatectl is a shell wrapper in the core snap calling out to timedatectl.real … could that be the issue here ?

jdstrand · November 1, 2017, 2:35pm

Actually, up above @jenny.murphy mentioned that she is calling ‘timedatectl set-ntp true’ from a java process. Do you have a small reproducer for this that is representative of how you are using java to invoke the program? A simple .java file is fine (I can put it in a snap easy enough).

jenny.murphy · November 1, 2017, 3:14pm

Hi,
Yes I will produce a code snippet for you over the coming days.
Thanks a lot.
Jenny

jenny.murphy · November 2, 2017, 1:03pm

name: hello-world-time-java # you probably want to 'snapcraft register ’
version: ‘0.1’ # just for humans, typically ‘1.2+git’ or ‘1.3.2’
summary: Hello World Java Program
description: Simple Hello World Java Program which also uses timedatectl
grade: devel # must be ‘stable’ to release into candidate/stable channels
confinement: devmode # use ‘strict’ once you have the right plugs and slots

apps:
hello-world-java:
command: bin/wrapper
plugs: [time-control, timezone-control, timeserver-control, home, network-control]

parts:
hello:
plugin: ant
source: .
wrapper:
plugin: make
source: .

package oata;

public class HelloWorld {
public static void main(String[] args) {
System.out.println(“Hello World from Java!”);

    try {
    // Disable NTP
    String[] command = new String[]{
       "timedatectl",
        "set-ntp",
        "false"};

Runtime rt = Runtime.getRuntime();
Process p = rt.exec(command);
int exitCode = p.waitFor();

System.out.println(
    	"Command 'timedatectl set-ntp false "
        + " exit code: "
	+ exitCode);
    } catch (Exception e) {
       System.out.println(
    	"Exception caught : "
	+ e.getMessage());
    }
}

}

jenny.murphy · November 2, 2017, 1:05pm

I posted the snapcraft file and the java code above.
However I don’t get the @{PROC}/1/environ r warning with this program.

How I am calling timedatectl is exactly the same.

The only difference my real snap runs as a service as opposed to command line and has a lot of other interfaces connected.

awe · November 2, 2017, 10:23pm

Does your sample code still trigger the ptrace warning? Also, aside from the warning, does this affect the outcome of your call to ‘timedatectl set-ntp’ (ie. does it function properly)?

jenny.murphy · November 3, 2017, 8:50am

Yes the outcome of the call is always as expected , in the sample program and the real program. No I do not get any ptrace warning from the sample code.

awe · November 7, 2017, 8:38pm

I modified some sample Go daemon code to execute timedatectl and wasn’t able to reproduce the error at first. I tried using a full path for the executable /usr/bin/timedatectl and just using the name of the binary.

My code used the status, set-ntp, set-timezone, and set-time functions. One thing I did discover is that if you use the set-time operation, it fails due to a quoting problem in the timedatectl wrapper script. You have a pass the time as a quoted string like this:

sudo timedatectl set-time "2012-10-30 18:17:16"

…and the quotes get dropped in the wrapper script which if the command isn’t “set-timezone”, just does:

$TIMEDATECTL $@

I’ll file a bug for this.

When running my daemon snap, I did see some apparmor errors for timedatectl, but I never saw any for timedatectl.real until I modified the snap to declare plugs for timezone-control, time-control, and timeserver-control. At this point, I started seeing apparmor errors for the various libraries that timedatectl.real actually uses, however I still didn’t see the ptrace error or the /proc/1/environ error. It wasn’t until I actually connected the plugs for the three time interfaces that these errors were logged.

So, to trigger these errors:

Ensure the snap declares plugs for time*-control
Ensure that the snap app that uses timedatectl is a simple daemon
Ensure that the snap daemon calls timedatectl set-ntp true
Ensure that all the time* plugs are connected

niemeyer · November 9, 2017, 5:53pm

@pstolowski Would you mind to have a look into this quoting issue?

pstolowski · November 10, 2017, 9:18am

Sure, will look at this shortly.

chipaca · November 10, 2017, 10:42am

could you link the bug please?