Creating a policy as non-root not working as expected

[jaywryan]

I am testing the functionality that was added with this PR #78

When attempting to create a policy, per the PR and the tests, I don't get the same results. When launching a container to create a policy from ie.

podman run --device /dev/tty0 fedora /bin/bash

I don't get the device to map. I am running this rootless. When doing an inspect on the container, I see this

"Devices": []

If I run the container as root, the device maps. I am not sure if this is the way udicapodman is supposed to work. Obviously, udica can't create a policy that would allow for the device if its not a part of the container metadata. Does Udica require the container used to build the policy to have the correct permissions? If so, perhaps this needs to be added to the documentation. If not, I am wondering if devices somehow work differently than volumes for example. Perhaps devices can't even map if they are denied by selinux. Since the device can't even be mounted, udica would never even know that it needs to build a policy for it. I hope this makes sense, I am new to Udica, but it appears to be solving an issue I've had for quite some time, it just isn't working the way I expect it to.

[vmojzis]

I am testing the functionality that was added with this PR #78

When attempting to create a policy, per the PR and the tests, I don't get the same results. When launching a container to create a policy from ie.

podman run --device /dev/tty0 fedora /bin/bash

I don't get the device to map. I am running this rootless. When doing an inspect on the container, I see this

"Devices": []

Udica needs the device to be listed here.

If I run the container as root, the device maps. I am not sure if this is the way ~udica~podman is supposed to work. Obviously, udica can't create a policy that would allow for the device if its not a part of the container metadata. Does Udica require the container used to build the policy to have the correct permissions? If so, perhaps this needs to be added to the documentation. If not, I am wondering if devices somehow work differently than volumes for example. Perhaps devices can't even map if they are denied by selinux. Since the device can't even be mounted, udica would never even know that it needs to build a policy for it. I hope this makes sense, I am new to Udica, but it appears to be solving an issue I've had for quite some time, it just isn't working the way I expect it to.

Udica just collects all the devices it finds in inspect_data[0]["HostConfig"]["Devices"] and for each one it tries to find all labels that can be expected in the "PathOnHost" path. First it browses all file context definitions searching for given path (it needs access to the security policy for this to work) and then it tries to get the context of the directory itself (this may require access to the "PathOnHost" directory and all its parent directories).
TLDR: Udica itself needs to have access to the device and the security policy of your system, and the device needs to be listed in the container metadata (not sure how podman handles devices, but based on the testing you did it seems that you need to run the container as root at least to get the correct metadata).

[jaywryan]

This is probably worth while information to include in the documentation. Specifically the difference in how volumes and devices are handled in the container engine. My experience was that a volume, even if you don't have permission would mount in, and therefore udica could create a module for it, a device on the other hand will refuse to mount and udica can not create a module for it. You will need a machine or a user to run the container with the correct permissions to mount the device in order for udica to create the proper configuration.

[gssdromen]

same issue here, any updates? thanks

[vmojzis]

@gssdromen Frankly I don't know what I can do to help in this situation. Udica needs to know of any devices that it should account for in the policy. This information needs to come from the container inspect data. If the container engine doesn't have access to the device in question, It will not get mounted and will not be present in the inspect data.