Bug 1489166 - F26 cloud image fails to provision on Azure: selinux
Summary: F26 cloud image fails to provision on Azure: selinux
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 26
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1477333
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-06 20:47 UTC by Brent Baude
Modified: 2017-10-20 12:15 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-20 12:15:01 UTC
Type: Bug


Attachments (Terms of Use)

Description Brent Baude 2017-09-06 20:47:51 UTC
Description of problem:

We observe an selinux issue when provisioning the Fedora 26 cloud-image on Azure.  Specifically an AVC that looks like:

type=AVC msg=audit(1504729740.013:72): avc:  denied  { getattr } for  pid=652 comm="dhclient-script" path="/run/cloud-init/enabled" dev="tmpfs" ino=13546 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0

type=AVC msg=audit(1504729742.302:76): avc:  denied  { getattr } for  pid=659 comm="dhclient-script" path="/run/cloud-init/enabled" dev="tmpfs" ino=13546 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0

Additional information:

[fedora@localhost ~]$ rpm -qa | grep selinux-policy
selinux-policy-3.13.1-260.3.fc26.noarch
selinux-policy-targeted-3.13.1-260.3.fc26.noarch
[fedora@localhost ~]$ rpm -qa | grep cloud-init
cloud-init-0.7.9-8.fc26.noarch
[fedora@localhost ~]$ ls -lZ /run/cloud-init/enabled 
-rw-r--r--. 1 root root system_u:object_r:init_var_run_t:s0 0 Sep  6 20:28 /run/cloud-init/enabled
[fedora@localhost ~]$ ls -lZ /run/cloud-init
total 4
-rw-r--r--. 1 root root system_u:object_r:init_var_run_t:s0 564 Sep  6 20:28 cloud-init-generator.log
-rw-r--r--. 1 root root system_u:object_r:init_var_run_t:s0   0 Sep  6 20:28 enabled
-rw-r--r--. 1 root root system_u:object_r:var_run_t:s0        0 Sep  6 20:28 network-config-ready
lrwxrwxrwx. 1 root root system_u:object_r:var_run_t:s0       36 Sep  6 20:33 result.json -> ../../var/lib/cloud/data/result.json
lrwxrwxrwx. 1 root root system_u:object_r:var_run_t:s0       36 Sep  6 20:33 status.json -> ../../var/lib/cloud/data/status.json

Comment 2 Brent Baude 2017-09-15 20:45:18 UTC
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;

Comment 3 Brent Baude 2017-09-19 20:46:01 UTC
switching to the selinux policy component now that we have the AVC identified.

Comment 4 Lukas Vrabec 2017-09-20 16:14:31 UTC
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

Comment 5 Dusty Mabe 2017-09-20 19:54:01 UTC
lukas,

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

Comment 6 Brent Baude 2017-09-20 20:10:17 UTC
@Lukas, that would be my only guess as well.

Comment 7 Daniel Walsh 2017-09-25 17:17:18 UTC
Since cloud-init is running as init_t, it will create content under /run as init_var_run_t.

Comment 8 Daniel Walsh 2017-09-25 17:26:20 UTC
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

Comment 9 Lukas Vrabec 2017-09-29 08:33:12 UTC
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?

Comment 10 Daniel Walsh 2017-09-29 10:12:01 UTC
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.

Comment 11 Dusty Mabe 2017-10-02 18:03:47 UTC
(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?

Comment 12 Dusty Mabe 2017-10-02 18:39:25 UTC
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.

Comment 13 Lukas Vrabec 2017-10-03 14:42:58 UTC
Could you remove these files enabled and cloud-init-generator.log and then try to reproduce it again? 

Thanks,
Lukas.

Comment 14 Dusty Mabe 2017-10-03 18:00:31 UTC
(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

Comment 15 Lukas Vrabec 2017-10-04 13:21:55 UTC
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.

Comment 16 Brent Baude 2017-10-04 21:22:08 UTC
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

Comment 17 Daniel Walsh 2017-10-06 13:46:19 UTC
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?

Comment 18 Dusty Mabe 2017-10-06 13:54:49 UTC
(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`.

Comment 19 Dusty Mabe 2017-10-06 14:53:37 UTC
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.

Comment 20 Dusty Mabe 2017-10-06 16:47:55 UTC
upstream pull request that fixes the issue: https://github.com/fedora-selinux/selinux-policy-contrib/pull/31

Comment 21 Dusty Mabe 2017-10-20 12:15:01 UTC
this is resolved now in f27 and rawhide


Note You need to log in before you can comment on or make changes to this bug.