libsmack 1.1: support for init systems running with selected Smack label

[rafal-krypa]

Systemd can be configured at build time to run with a specific Smack label (configure option --with-smack-run-label=STRING). Functionally this causes the systemd init process to perform the following actions:

• set the process label to SMACK_RUN_LABEL
• write the label to smackfs/ambient (Smack label applied to unlabeled network packets)
• write 0.0.0.0/0 SMACK_RUN_LABEL and 127.0.0.1 -CIPSO to smackfs/netlabel.

To support such use case in libsmack, we could provide a function that could be used by init systems like systemd to reliably start with a specific Smack label. Or it can be two functions, reusing existing smack_set_label_for_self() and a new, hereby proposed function smack_set_label_for_network(const char *label).

[rafal-krypa]

One more proposal, which seems most flexible and clean. As a part of solution to #109, we could have a new family of functions for operating on netlabels, just like existing API for CIPSO. Then only one simple function for setting ambient label would be needed. But this would clutter libsmack API a lot (5 functions for #109 and one more for ambient label).

[jobol]

Be aware that systemd is mounting smackfs at some time and that before it, the smackfs is not accessible. (we detected a problem of that kind in systemd upstream used by yocto and sent a patch to improve the caching)

Before the mounting, only /proc/***/attr/current is available.

[jarkkojs]

@rafal-krypa I didn't understand your connection to #109. I don't think smack_load_policy() must be "do everything" function. It makes sense only do those things in it that are easy and natural do in it. It isn't too much trouble to do a few smack_ function calls in systemd code.