search

agentultra / openstack-guest-agents-unix

Openstack Unix Guest Agent
Apache License 2.0
0 stars 1 forks source link

policy doesn't allow tmp file creation #2

Open agentultra opened 11 years ago

agentultra commented 11 years ago

The actual process used by the agent to update the system password is located in:

https://github.com/agentultra/openstack-guest-agents-unix/blob/issues/10/commands/password.py#L296

It looks like the message:

type=AVC msg=audit(1351020235.886:6): avc: denied { execute } for pid=774 comm="nova-agent" path=2F7661722F746D702F666669544E35745934202864656C6574656429 dev=xvda1 ino=393437 scontext=system_u:system_r:openstack_guest_agent_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file

in the audit log might be cause by this operation:

https://github.com/agentultra/openstack-guest-agents-unix/blob/issues/10/commands/password.py#L226

Either way, the function does create and rename a few files to a few different places. The policy should be updated to allow these or else we'll have to find a different way to set the system password.

prometheanfire commented 11 years ago

In reading more into this I kinda don't like /tmp/shadow.tmp.* to be made openstack_guest_agent_tmp_t, it seems like it's overstepping the bounds of file labeling. maybe if the file was in /tmp/openstack-guest-agent or something, but simply /tmp/shadow.tmp.* is too global.

It shouldn't be too dificult to modify the tmp storage location though then we can simply make one rule to have everything labeled openstack_guest_agent_tmp_t that is in /tmp/openstack-guest-agent/* which would be better for future maintainability (in case any other files would want to be modified)

alunduil commented 11 years ago

What about a transitional label so that it's marked only when openstack_t writes it? Then we give it write access to tmp_t dirs (which is probably has) and then the file is safe to it while it's being manipulated.

Something like the following might do it:

files_tmp_filetrans(openstack_t, oepnstack_tmp_t, file)

Then it's just a matter of being able to write to /etc/shadow*.

prometheanfire commented 11 years ago

well, it should already be able to write to /etc/shadow, since redhat seems to make those files etc_t. What worries me is that the AVC denial is for something being exec'd as tmp_t, why is it trying to exec something in /tmp, that's a big NoNo.