Bug 1303514 - AVC denials on atomic host while running RHGS container
AVC denials on atomic host while running RHGS container
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.2
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Lukas Vrabec
Milos Malik
:
Depends On:
Blocks: 1294762
  Show dependency treegraph
 
Reported: 2016-02-01 02:05 EST by Mohamed Ashiq
Modified: 2017-01-02 07:48 EST (History)
14 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-89.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1294762
Environment:
Last Closed: 2016-11-03 22:41:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 5 Paul Moore 2016-02-09 08:14:30 EST
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.
Comment 6 Mohamed Ashiq 2016-02-09 08:27:19 EST
(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).
Comment 7 Paul Moore 2016-02-09 09:16:56 EST
(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.
Comment 8 Mohamed Ashiq 2016-02-09 09:27:51 EST
(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?
Comment 9 Paul Moore 2016-02-09 09:52:52 EST
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).
Comment 10 Daniel Walsh 2016-02-09 10:18:06 EST
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.
Comment 11 Paul Moore 2016-02-09 10:51:06 EST
(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.
Comment 12 Daniel Walsh 2016-02-09 11:00:21 EST
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.
Comment 13 Mohamed Ashiq 2016-02-09 11:29:25 EST
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.
Comment 14 Daniel Walsh 2016-02-09 12:30:50 EST
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.
Comment 15 Daniel Walsh 2016-02-09 12:31:30 EST
If we just add an attribute logfile to svirt_sandbox_file_t, then this would fix the issue.
Comment 16 Paul Moore 2016-02-10 05:26:58 EST
(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.
Comment 17 Miroslav Grepl 2016-02-10 07:28:01 EST
(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.
Comment 18 Daniel Walsh 2016-02-10 09:20:23 EST
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)
Comment 19 Miroslav Grepl 2016-04-29 05:19:42 EDT
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.
Comment 21 Lukas Vrabec 2016-07-04 04:57:16 EDT
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.
Comment 29 errata-xmlrpc 2016-11-03 22:41:21 EDT
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

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