RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 602463 - Your system may be seriously compromised! /sbin/modprobe tried to load a kernel module.
Summary: Your system may be seriously compromised! /sbin/modprobe tried to load a kern...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Chris Lalancette
QA Contact: Virtualization Bugs
URL:
Whiteboard: setroubleshoot_trace_hash:5a5ffb19fb1...
Depends On:
Blocks: Rhel6.1LibvirtTier2 654579
TreeView+ depends on / blocked
 
Reported: 2010-06-09 21:44 UTC by Matěj Cepl
Modified: 2011-02-18 14:56 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 654579 (view as bug list)
Environment:
Last Closed: 2011-02-18 14:56:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Matěj Cepl 2010-06-09 21:44:46 UTC 
Souhrn:

Your system may be seriously compromised! /sbin/modprobe tried to load a kernel
module.

Podrobný popis:

[SELinux je v tolerantním režimu. Přístup byl povolen.]

SELinux has prevented modprobe from loading a kernel module. All confined
programs that need to load kernel modules should have already had policy written
for them. If a compromised application tries to modify the kernel this AVC will
be generated. This is a serious issue. Your system may very well be compromised.

Povolení přístupu:

Contact your security administrator and report this issue.

Další informace:

Kontext zdroje                system_u:system_r:virtd_t:s0-s0:c0.c1023
Kontext cíle                 system_u:system_r:virtd_t:s0-s0:c0.c1023
Objekty cíle                 None [ capability ]
Zdroj                         modprobe
Cesta zdroje                  /sbin/modprobe
Port                          <Neznámé>
Počítač                    (removed)
RPM balíčky zdroje          module-init-tools-3.9-13.el6
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.7.19-23.el6
Selinux povolen               True
Typ politiky                  targeted
Vynucovací režim            Permissive
Název zásuvného modulu     sys_module
Název počítače            (removed)
Platforma                     Linux (removed) 2.6.32-33.el6.x86_64 #1
                              SMP Thu Jun 3 13:00:03 EDT 2010 x86_64 x86_64
Počet upozornění           1
Poprvé viděno               St 9. červen 2010, 23:41:39 CEST
Naposledy viděno             St 9. červen 2010, 23:41:39 CEST
Místní ID                   7cd18ab0-5436-4992-9502-de835a20617b
Čísla řádků              

Původní zprávy auditu      

node=(removed) type=AVC msg=audit(1276119699.300:19): avc:  denied  { sys_module } for  pid=1901 comm="modprobe" capability=16  scontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=capability

node=(removed) type=SYSCALL msg=audit(1276119699.300:19): arch=c000003e syscall=175 success=yes exit=0 a0=1a80200 a1=8220 a2=1a784c0 a3=7fffd60d9cf0 items=0 ppid=1887 pid=1901 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/sbin/modprobe" subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  sys_module,modprobe,virtd_t,virtd_t,capability,sys_module
audit2allow suggests:

#============= virtd_t ==============
allow virtd_t self:capability sys_module;
Comment 2 RHEL Program Management 2010-06-09 22:13:01 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Daniel Walsh 2010-06-10 12:32:46 UTC 
Daniel,  Is libvirt supposed to be able to execute modprobe?
Comment 4 Daniel Berrangé 2010-06-10 12:42:33 UTC 
Yes & no. In theory we need it for PCI hotplug to load  'pci-stub' or 'pciback', but those are both compiled into the kernel these days, so it shouldn't be that which triggered this AVC.

I'm wondering if perhaps some other library libvirt calls is running modprobe. I'd really need to see what the argument to modprobe were to identify what's running it.

IMHO we should avoid giving libvirt modprobe privileges.
Comment 5 Bill Nottingham 2010-06-10 16:12:03 UTC 
Is there a way to fix the error message? "/sbin/modprobe tried to load a kernel module" is not particularly informative as to the actual problem.
Comment 7 Chris Lalancette 2010-06-28 18:28:23 UTC 
As Dan mentioned in comment #4, the only modprobe that libvirt itself ever does
is for pci-stub or pci-back.  And running a RHEL-6 kernel, the former is
built-in (while the latter doesn't exist), so we should never run this
particular modprobe.  That being said, if you were running a custom kernel of
some manner, this could trigger.  Were you running a custom kernel?  What
kernel were you running exactly?

If this is not a custom kernel, then the only other explanation is that one of
the libraries libvirt requires tried to do this modprobe.  What were you doing
at the time you got this AVC?  Can you reliably reproduce this?  If so, what
are the steps to reproduce?

Thanks,
Chris Lalancette
Comment 8 Matěj Cepl 2010-07-13 19:20:30 UTC 
(In reply to comment #7)
> As Dan mentioned in comment #4, the only modprobe that libvirt itself ever does
> is for pci-stub or pci-back.  And running a RHEL-6 kernel, the former is
> built-in (while the latter doesn't exist), so we should never run this
> particular modprobe.  That being said, if you were running a custom kernel of
> some manner, this could trigger.  Were you running a custom kernel?  What
> kernel were you running exactly?

I haven't build a kernel since 2006, when I switched to Fedora ;) (and once for some testing purposes half a year ago). No, this was just the latest RHEL-6 kernel from repos.

> If this is not a custom kernel, then the only other explanation is that one of
> the libraries libvirt requires tried to do this modprobe.  What were you doing
> at the time you got this AVC?  Can you reliably reproduce this?  If so, what
> are the steps to reproduce?

Not sure what I did, probably just starting a virtual machine. And no I cannot reproduce it.
Comment 9 Carl G. 2010-07-13 19:32:53 UTC 
> Not sure what I did, probably just starting a virtual machine. And no I cannot
> reproduce it.    

Same here, i do not run a custom kernel. I remember starting libvirtd and libvirt-guests and running a VM around the time i saw this AVC.

kernel-2.6.35-0.27.rc4.git0.fc14.x86_64
selinux-policy-3.8.6-1.fc14.noarch
Comment 20 Dave Allan 2011-02-18 14:56:08 UTC 
Since we do not have enough information to understand what's happening here, and the behavior no longer seems to be present, I'm closing as insufficient data.  As always, please reopen if it reappears.
Note You need to log in before you can comment on or make changes to this bug.