interfaces: add random interface

[femdom]

Allow access to the /dev/hwrng device (used in the Raspberry Pi).

[niemeyer]

We can probably name this as simply "random", and include in this interface any random-number generation infrastructure available in the system.

Otherwise, just a few notes:

[niemeyer]

Why? This looks like something we should hand off by default.

[niemeyer]

Missing a /sys prefix.

[femdom]

@niemeyer , I fixed the code after your comments.

For the some reason tests fail because of timeout.

[niemeyer]

@femdom Thanks. We had some issues last week with test machine contention (too many tests, not enough machines), which resulted in them waiting too much for a machine to be available. Situation is normalized now and I've restarted the test.

@jdstrand can you please have a look at this one when you have a moment?

[niemeyer]

Travis tests passing.

[stolowski]

@femdom FYI, I've updated this PR for the latest API changes.

[femdom]

Thanks, @stolowski! Checks passed!

[jdstrand]

Several open questions in addition to requested changes.

@niemeyer - you should weigh in on 'hardware-random' vs 'hardware-random-control' and 'hardware-random-observe'.

[jdstrand]

I think this should be renamed to hardware-random or even hardware-random-control since random implies /dev/random and /dev/urandom and we already allow access to those by default.

I also think this should be: deny-auto-connection: true since direct access to /dev/hwrng is not normally needed and typically only used by applications such as rng-tools to mix /dev/hwrng into kernel entropy. More importantly, a hardware-specific kernel driver for /dev/hwrng could be implemented in any number of ways including with weak (or non-existent) entropy (the kernel does not perform any fitness tests). Since this interface allows changing the hwrng via sysfs, it is possible to switch out a stronger rng for a weaker one and this is something that should not be auto-connected.

Perhaps this could be broken out into two interfaces:

• hardware-random-observe - read access to relevant files from this PR, manually connected
• hardware-random-control - all of hardware-random-observe plugs write access to /sys/class/misc/hw_random/rng_current for changing the hwrng, manually connected

I would argue that hardware-random-observe would still be a manual connection because the access is not typically needed, the device may not be provided by the kernel and there is no guarantee that the fitness of the device is good (ie, the gadget developer or device owner should decide whether a snap should use /dev/hwrng).

[niemeyer]

All recommendations, including naming, feel sound. 👍

[zyga]

I'm doing this change now.

[jdstrand]

Please change this to:

# Description: allow direct access to the hardware random number generator device. Usually,
# the default access to /dev/random is sufficient, but this allows applications such as rng-tools
# to use /dev/hwrng directly or change the hwrng via sysfs. For details, see
# https://www.kernel.org/doc/Documentation/hw_random.txt

[zyga]

Done

[jdstrand]

This should just be 'r'.

[zyga]

Done though have a look, I'm not sure if the control-vs-observe split applies here

[jdstrand]

This is a directory, not a file. This rule should be:

/sys/devices/virtual/misc/ r,
/sys/devices/virtual/misc/hw_random/rng_{available,current} r,
# Allow changing the hwrng
/sys/devices/virtual/misc/hw_random/rng_current w,

The above assumes you actually need write access to /sys/devices/virtual/misc/hw_random/rng_current. Do you?

You should also add this rule:

/run/udev/data/c10:183 r,

[zyga]

Done

[femdom]

Understood, thanks.

[jdstrand]

@femdom - just to be clear, please don't make any changes just yet until these open questions are answered.

[femdom]

Just updating the ticket. Let me know if I can fix addressed issues.

[niemeyer]

@femdom This is good to move on following @jdstrand's advices.

[zyga]

I just updated this according to @jdstrand specification. Let me know if there's anything more needed, I can quickly iterate and hopefully land this interface.

[jdstrand]

Approving since my feedback is all nitpicks, but please update before committing.

BTW - thanks for the alphabetizing! :)

[jdstrand]

Nit: can you wrap these to 80 chars?

[zyga]

Done

[jdstrand]

Can you move this to below /dev/hwrng? It corresponds to that device and this access isn't needed for changing the hwrng. I also like to have blcnks lines before comments in policy, for readability. Eg:

 +/dev/hwrng rw,
 +/run/udev/data/c10:183 r,
 +/sys/devices/virtual/misc/ r,
 +/sys/devices/virtual/misc/hw_random/rng_{available,current} r,
 +
 +# Allow changing the hwrng
 +/sys/devices/virtual/misc/hw_random/rng_current w,

[zyga]

Done

[jdstrand]

Can you add above this 'return' (for consistency with other interfaces):

// Allow what is allowed in the declarations

[zyga]

Done

[jdstrand]

Can you move this under /dev/hwrng, like above?

[zyga]

Done :-)

[jdstrand]

and add above this 'return':

// Allow what is allowed in the declarations

[zyga]

Also done :-)