the te file:

[bbaude@baude-atomic-2 ~]$ cat fixdhclient.te 

module fixdhclient 1.0;

require {
	type init_var_run_t;
	type dhcpc_t;
	class file getattr;
}

#============= dhcpc_t ==============
allow dhcpc_t init_var_run_t:file getattr;

switching to the selinux policy component now that we have the AVC identified.

Brent, 

Do we know why /run/cloud-init has init_var_run_t label? I don't think that this is correct. 

On my rawhide only dir with these context is /var/run/systemd/ . 

 # semanage fcontext -l | grep init_var_run_t
/var/run/systemd(/.*)?                             all files          system_u:object_r:init_var_run_t:s0

lukas,

Is it because the files are populated during startup? I have no idea why those files have that policy.

@Lukas, that would be my only guess as well.

Since cloud-init is running as init_t, it will create content under /run as init_var_run_t.

If we want cloud-init to have a label that dhcpc_t can read we could change it to net_conf_t.

Could add a transition rule that states with init_t creates a dirctory named clound-init it creates it as net_conf_t

files_pid_filetrans(init_t, net_conf_t, dir, "cloud-init")

Add a file context

/run/cloud-init(/.*)? system_u:object_r:net_conf_t:s0

Dan, 

I'm fine with this transition rule, I'll add it. But that cloud-init should run in some confined domain instead of init_t. Do you have more info about cloud-init?

cloud-init is basically an init program that can be setup to do anything.  It configures an VM when it boots in the cloud.  Not sure how to configure it other then maybe run it as initrc_t, or something like that.

(In reply to Lukas Vrabec from comment #9)
> Dan, 
> 
> I'm fine with this transition rule, I'll add it. But that cloud-init should
> run in some confined domain instead of init_t. Do you have more info about
> cloud-init?

looks like this change made it into `selinux-policy-3.13.1-290.fc28` and `selinux-policy-3.13.1-283.5.fc27`. 


(In reply to Daniel Walsh from comment #10)
> cloud-init is basically an init program that can be setup to do anything. 
> It configures an VM when it boots in the cloud.  Not sure how to configure
> it other then maybe run it as initrc_t, or something like that.

i'm not sure - Lukas, thoughts?

I tested out the new rpm in rawhide:

```
[root@cloudhost ~]# rpm -q selinux-policy
selinux-policy-3.13.1-290.fc28.noarch
```

I see this on a booted system now (selinux=permissive): 

```
[root@cloudhost ~]# ls -lZ /run/cloud-init/
total 4
-rw-r--r--. 1 root root system_u:object_r:init_var_run_t:s0 560 Oct  2 18:33 cloud-init-generator.log
-rw-r--r--. 1 root root system_u:object_r:init_var_run_t:s0   0 Oct  2 18:33 enabled
-rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0       0 Oct  2 18:33 network-config-ready
lrwxrwxrwx. 1 root root system_u:object_r:net_conf_t:s0      36 Oct  2 18:33 result.json -> ../../var/lib/cloud/data/result.json
lrwxrwxrwx. 1 root root system_u:object_r:net_conf_t:s0      36 Oct  2 18:33 status.json -> ../../var/lib/cloud/data/status.json
```

I still get the denials reported in the description of this BZ:


```
[root@cloudhost ~]# ausearch -m avc
----
time->Mon Oct  2 18:33:23 2017
type=AVC msg=audit(1506969203.852:79): avc:  denied  { getattr } for  pid=634 comm="dhclient-script" path="/run/cloud-init/enabled" dev="tmpfs" ino=13084 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
```

Seems like what we did (net_conf_t) only affected the other files in the /run/cloud-init/ directory, not the ones we were getting denials for.

Could you remove these files enabled and cloud-init-generator.log and then try to reproduce it again? 

Thanks,
Lukas.

(In reply to Lukas Vrabec from comment #13)
> Could you remove these files enabled and cloud-init-generator.log and then
> try to reproduce it again?

I removed enabled and cloud-init-generator.log and rebooted the system (triggers another run of cloud-init). The files come back the same way:

[root@cloudhost cloud-init]# ls -lZ 
total 4
-rw-r--r--. 1 root root system_u:object_r:init_var_run_t:s0 560 Oct  3 17:59 cloud-init-generator.log
-rw-r--r--. 1 root root system_u:object_r:init_var_run_t:s0   0 Oct  3 17:59 enabled

Dusty, 
It looks like these files were moved from some another directory not created in /run/cloud-init/ 

Do you know how these files are created? 

Lukas.

Lukas,

I believe enabled is created via the cloud-init-generator script which lives in:

/usr/lib/systemd/system-generators/

The code for the generator can be seen here -> https://git.launchpad.net/cloud-init/tree/systemd/cloud-init-generator#n146

We should label those cloud_init_exec_t

See if you 

chcon -t cloud_init_exec_t /usr/lib/systemd/system-generators/cloud-init*

Then reboot

Does the problem go away?

(In reply to Daniel Walsh from comment #17)
> We should label those cloud_init_exec_t
> 
> See if you 
> 
> chcon -t cloud_init_exec_t /usr/lib/systemd/system-generators/cloud-init*
> 
> Then reboot
> 
> Does the problem go away?


unfortunately it doesn't seem to go away. I deleted `cloud-init-generator.log` and `enabled` files. Then `chcon -t cloud_init_exec_t /usr/lib/systemd/system-generators/cloud-init*`, then did a reboot. The new files still come back `var_run_t`.

ahh - talking to dwalsh we realize `var_run_t` != `init_var_run_t`. So the `chcon -t cloud_init_exec_t /usr/lib/systemd/system-generators/cloud-init*` did have an effect. 

As reported in IRC I do still get denials though: 

```
type=AVC msg=audit(1507300574.085:70): avc:  denied  { getattr } for  pid=611 comm="dhclient-script" path="/run/cloud-init/enabled" dev="tmpfs" ino=13943 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=1
```

debugging a bit farther we added an `id -Z` statement to the generator. Before `chcon -t cloud_init_exec_t /usr/lib/systemd/system-generators/cloud-init*` the context is:

```
system_u:system_r:unconfined_service_t:s0
```

After chcon the context of the running generator is:

```
system_u:system_r:cloud_init_t:s0
```

Which looks right. dwalsh is checking the policy now.

upstream pull request that fixes the issue: https://github.com/fedora-selinux/selinux-policy-contrib/pull/31

this is resolved now in f27 and rawhide