Bug 1303514

I'm going to cherry pick one of the AVC denials from the original problem report and abstract out some details to explain the problem and what I believe to be the proper solution:

[XXXXX.XXXXXX] type=1400 audit(1451427122.156:5): avc:  denied  { ... } for
  pid=23010 comm="logrotate" path="/var/log/application/log_data.log"
  dev="dm-1" ino=12618760 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
  tcontext=system_u:object_r:svirt_sandbox_file_t:s0 tclass=file

In the example above we have a logfile, "log_data.log", that was created for use by a container (at least I assume so give its svirt_sandbox_file_t label) but being managed by an application in the host (in this particular case, logrotate, running as logrotate_t).  If the file needs to be accessed from within the container, it should be managed within the container as well; in other words, if your log files are being written in a container you should also run logrotate in that same container.

(In reply to Paul Moore from comment #5)
> I'm going to cherry pick one of the AVC denials from the original problem
> report and abstract out some details to explain the problem and what I
> believe to be the proper solution:
> 
> [XXXXX.XXXXXX] type=1400 audit(1451427122.156:5): avc:  denied  { ... } for
>   pid=23010 comm="logrotate" path="/var/log/application/log_data.log"
>   dev="dm-1" ino=12618760
> scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023
>   tcontext=system_u:object_r:svirt_sandbox_file_t:s0 tclass=file
> 
> In the example above we have a logfile, "log_data.log", that was created for
> use by a container (at least I assume so give its svirt_sandbox_file_t
> label) but being managed by an application in the host (in this particular
> case, logrotate, running as logrotate_t).  If the file needs to be accessed
> from within the container, it should be managed within the container as
> well; in other words, if your log files are being written in a container you
> should also run logrotate in that same container.

AFAIK logrotate is happening in the container which writes the log to /var/log/glusterfs. Still logging avc denial. Just out of curiosity tried relabeling svirt_sandbox_file_t to glusterd_log_t after getting in the container, which does seem to solve the issue(not seeing avc denials for logrotate).

(In reply to Mohamed Ashiq from comment #6)
> AFAIK logrotate is happening in the container which writes the log to
> /var/log/glusterfs. Still logging avc denial. Just out of curiosity tried
> relabeling svirt_sandbox_file_t to glusterd_log_t after getting in the
> container, which does seem to solve the issue(not seeing avc denials for
> logrotate).

The AVC denial would indicate that the logrotate application is running on the host, although since you've bind mounted the directory in which logrotate is managing files, you will see the effects of logrotate in both the host and the container.

(In reply to Paul Moore from comment #7)
> (In reply to Mohamed Ashiq from comment #6)
> > AFAIK logrotate is happening in the container which writes the log to
> > /var/log/glusterfs. Still logging avc denial. Just out of curiosity tried
> > relabeling svirt_sandbox_file_t to glusterd_log_t after getting in the
> > container, which does seem to solve the issue(not seeing avc denials for
> > logrotate).
> 
> The AVC denial would indicate that the logrotate application is running on
> the host, although since you've bind mounted the directory in which
> logrotate is managing files, you will see the effects of logrotate in both
> the host and the container.

If I disable logrotate completely in host, the container's logrotate application should rotate logs without denials, right?

One of the policy experts on this BZ would likely be able to provide a better answer (mgrepl? lvrabec?), but I suspect that running logrotate in the container should work without problem.  The only catch is that depending on the internals of logrotate the resulting managed files may be private to the container (they will be labeled with the container's security label and thus not readable by other containers).

We should allow logrotate to manage svirt_sandbox_file_t files, since users will be volume mounting log directories into containers and writing them.  

Containers should not be writing content inside of the container image, these logs should be going to the host.  Containers in general should not be running tools like logrotate, they should be single microservices, and logrotate should be running on the host or it could be running as a special SPC container that can manage log files on the host.

(In reply to Daniel Walsh from comment #10)
> We should allow logrotate to manage svirt_sandbox_file_t files, since users
> will be volume mounting log directories into containers and writing them.  
> 
> Containers should not be writing content inside of the container image,
> these logs should be going to the host.  Containers in general should not be
> running tools like logrotate, they should be single microservices, and
> logrotate should be running on the host or it could be running as a special
> SPC container that can manage log files on the host.

I know we've got the whole "containers don't contain" motto, but having the host manage data generated by the container seems like an area of risk.  Although, to be fair, while I haven't looked at the svirt_sandbox_* policy in detail, I suspect we do much worse already.

Sure but it is about the user setting up that the containers can write to the content.  Containers would not be able to write to /var/log unless users mounted the containers with a relabel call.

mkdir /var/log/containercontent
docker run -d /var/log/containercontent:/var/log:Z myapp 

Something like this.

The setup we have is one RedHat Gluster Storage container(which uses systemd) per atomic host with var/log/glusterfs:/var/log/glusterfs:z bind mount along with few more. Is there a way to run logrotate in the container without AVC denials.

These AVC denials are happening on the host logrotate, If logrotate ran within the container it would probably work fine, but the logrotate on the host would still cause AVC's.

If we just add an attribute logfile to svirt_sandbox_file_t, then this would fix the issue.

(In reply to Daniel Walsh from comment #12)
> Sure but it is about the user setting up that the containers can write to
> the content.  Containers would not be able to write to /var/log unless users
> mounted the containers with a relabel call.
> 
> mkdir /var/log/containercontent
> docker run -d /var/log/containercontent:/var/log:Z myapp 
> 
> Something like this.

Ungh.  For obvious reasons I'm not a fan of relabeling things, especially existing log data.  I don't have a problem with bind mounts as the file labels are preserved; but I do cringe a bit when you relabel those files, either through a context mount or some other relabeling operation.

I suppose allowing the logrotate domain access to the container file types is not the end of the world, especially if we start moving towards less granular domains in the host.  The host inherently needs to be able to access the containers already (although perhaps not in this particular manner) so opening up another access vector from the host to the container is not the end of the world.  I'm just not necessarily excited about it.

(In reply to Daniel Walsh from comment #12)
> Sure but it is about the user setting up that the containers can write to
> the content.  Containers would not be able to write to /var/log unless users
> mounted the containers with a relabel call.

We can say it for various cases. Will we support all of them?

> 
> mkdir /var/log/containercontent
> docker run -d /var/log/containercontent:/var/log:Z myapp 
> 
> Something like this.

Right this is about allowing other parts of the system to protect the host.  Not ideal, I suppose we could add booleans, but breaking things by default sucks also.

The attack vector here is that a container could create log content that could cause the logrotate/log* programs to do something evil.  But the admin has to mount in a part of the OS into the container for this to happen, and has to relabel the directory to something the container can write.

A rogue container would not be able to jump into /var/log and start writing random content, unless the admin sets the appropriate labels.  (Using docker run -v /var/log/gluster:/var/log/gluster:Z)

Ok not sure what is a correct solution here. We can add an exception here but really not sure if it is a correct way.

After reading whole thread, I don't see any correct way how to handle it. I would say that we need add boolean for this issue, as Dan mentioned, we don't want breaking things by default.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2283.html