Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: vserver and vprocunhide Date: Mon, 23 Oct 2006 17:51:50 +0200
I have read that vserver and selinux have conflicts, is that true?
I am using a vserver and it tries to access ( to /proc/1 (init) labelled as
unconfined, that means, it tries to {getattr search} over the
directory /proc/1 and audit show me a denied. Vprocunhide have a list of
directories of /proc to "unhide" for vserver. The problem is that I can't
add /proc/1 in vprocunhide (I receive an error when
start /etc/init.d/vprocunhide restart). I can't relabel /proc/1 using chcon
or setfiles. I can't write
# Confined domains must never see unconfined domain's /proc/pid entries. neverallow { domain -unrestricted -snmpd_t -pegasus_t } unconfined_t:dir { getattr search }; What I have done is substract also the vserver daemon: neverallow { domain -unrestricted -snmpd_t -pegasus_t -vserver_test} unconfined_t:dir { getattr search }; and then I can write allow vserver_test_t unconfined_t:dir { getattr search }; Don't seems very elegant this solution, is the right one?
2.)
/etc/init.d/vserver_test restart Then I see the following denied message:
Oct 23 16:45:02 cnsu kernel: audit(1161621902.211:1167): avc: denied
and audit2allow writes the next allow initrc_t vprocunhide_t:dir mounton; but when this allow is adedd and I compile I see this message
assertion on line 45221 violated by allow initrc_t vprocunhide_t:dir
3.)
Oct 23 17:50:29 cnsu dbus: Can't send to audit system: USER_AVC pid=21488 uid=81 loginuid=-1 message=avc: 0 AV entries and 0/512 buckets used, longestchain length 0 It is not a denied, should I try to correct it? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: vserver and vprocunhide Date: Mon, 23 Oct 2006 13:53:06 -0400
Define "conflicts". You will need to configure SELinux policy appropriately, but I'm not aware of any fundamental conflict (e.g. there would be a real conflict if vserver used the LSM security fields or hooks, but it doesn't AFAIK).
> I am using a vserver and it tries to access ( to /proc/1 (init) labelled as What are your goals? Even aside from the question of allowing the vserver daemon to access /proc/1, why do you want to unhide /proc/1 in the vservers? Enabling a "confined" domain to access the /proc/pid entries of an unconfined domain is naturally undesirable. You could also move init into its own domain (already true in strict policy), so that you only have to allow access to init_t and not to all processes in unconfined_t, but even there I have to question why you are allowing this.
Note btw that there are different ways of configuring SELinux policy in
your environment:
> 2.) And what was that assertion? Likely just requires an attribute on vprocunhide_t to mark it as a mount point directory.
> ---------------------------------------------------------------------------------------------- Different kind of error - this means that dbusd could not send an audit message to the kernel. Do you have audit configured into your kernel? Is this process running within a vserver? Is the process running as root? Does it have the necessary capabilities to send audit messages? -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel Gil Mayol <Daniel.Gil-Mayol_at_brunel.de> subject: Re: vserver and vprocunhide Date: Tue, 24 Oct 2006 08:47:58 +0200
I read that "SELinux conflicts with Linux-VServer. Disable it in /etc/selinux/config (SELINUX=disabled)" about CentOS in this link: http://oldwiki.linux-vserver.org/CentOS_HowTo
> > I am using a vserver and it tries to access ( to /proc/1 (init) labelled I want to unhide /proc/1 because seems that vserver try to access there:
Oct 24 07:45:55 cnsu kernel: audit(1161675955.340:8577): avc: denied
{ search } for pid=28537 comm="pidof" name="1" dev=proc ino=65538
scontext=root:system_r:vserver_ids_t tcontext=user_u:system_r:unconfined_t
tclass=dir
I check which node correspond with ino=65538 with "find /proc -inum 65538" and
appear "/proc/1";
Move init into its own domain means relabel /proc/1 with for example 'init_t'? because I tried but this relabeling had no effect, it is, I have used "chcon -t init_t /proc/1/*", doesn't report me any error but after a "ls -Z" I see that the labelling haven't been done, is still "user_u:system_r:unconfined_t". I haven't found any definition of type init_t (something like "type init_t,..."), but after "sestatus -v" I see this line: 'Init context: user_u:system_r:unconfined_t' Should I try to change this init context? How? defining simply "type init_t ..." Could I profit the macro "init_service_domain()"?
> Note btw that there are different ways of configuring SELinux policy in I have two vservers: lets says 'vserver_1' and 'vserver_2'. Each one has its own labelling for bin and libs ('vserver_1_exec_t', 'vserver_1_lib_t') and the rest as 'vserver_1_modules_t' (the same for vserver_2). Other services like httpd don't use any specific labelling for each vserver.
> > 2.) This line in policy.conf correspond to the following rule:
# for gross mistakes in policy
that doesn't mention mounton.
> > ------------------------------------------------------------------------- I have check the config-2.6.16.9 file and there is "CONFIG_AUDIT=y", so audit is configured into my kernel.
> Is this process running within a vserver? After execute "ps aux | grep bus" I see the next: dbus 21879 0.0 0.3 10508 768 ? Ssl Oct23 0:00 dbus-daemon-1 --system so it is not running within a vserver, has its own process; And appear dbus instead of root, must be root? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel Gil Mayol <Daniel.Gil-Mayol_at_brunel.de> subject: Re: vserver and vprocunhide Date: Tue, 24 Oct 2006 09:19:46 +0200
I forgot to write -Z (--context), after "ps auxZ | grep bus", I see this: root:system_r:dbusd_t dbus 21879 0.0 0.3 10508 968 ? Ssl Oct23 0:00 dbus-daemon-1 --system So runs as root. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: vserver and vprocunhide Date: Tue, 24 Oct 2006 11:59:35 -0400
Oh, sorry - so it is the system bus. So it should be able to generate the audit messages. Possibly it lacks the following permissions: allow dbusd_t self:capability { audit_write }; allow dbusd_t self:netlink_audit_socket { create read writenlmsg_relay }; -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: vserver and vprocunhide Date: Tue, 24 Oct 2006 11:53:25 -0400
I'm not aware of any fundamental conflict, as I said. Just a matter of policy configuration. I believe that their advice to disable SELinux is just because they don't use SELinux themselves and don't want to have to help users figure out how to configure SELinux for vserver.
> I want to unhide /proc/1 because seems that vserver try to access there: That isn't clear. IIUC, you are getting these denials because you are trying to unhide /proc/1, not the other way around. So, again, why are you trying to unhide /proc/1, i.e. why does it need to be visible within the vserver instances?
> Oct 24 07:45:55 cnsu kernel: audit(1161675955.340:8577): avc: denied So now you have a vserver_ids_t domain; in the prior message you were showing a vserver_test_t domain. Are they different? Or did you just change the name? Where does this process run? On the "base" system or within each vserver instance?
> Move init into its own domain means relabel /proc/1 with for example 'init_t'? No, you wouldn't relabel the /proc/1 files; you would define a domain transition for init in your policy and then init would automatically run in init_t, and the /proc/1 files would automatically inherit that domain. This is already done in strict policy, as well as in newer targeted policies in Fedora Core.
> I haven't found any definition of type init_t (something like "type See the strict policy or a newer targeted policy from Fedora for examples. In those policies, the system doesn't start in unconfined_t; it starts in kernel_t, transitions to init_t upon running /sbin/init (the second time, after policy load), and then init_t transitions to other domains as appropriate.
> I have two vservers: lets says 'vserver_1' and 'vserver_2'. Each one has its I'm not sure I understand. By "vserver", do you mean daemon processes? But what about the rest of the processes running within each vserver instance? Does httpd run as httpd_t within each vserver instance?
> > And what was that assertion? Likely just requires an attribute on I thought that vprocunhide_t was a file type, not a domain. Did you put "domain" in its attribute list? That would be a mistake. Domains are for processes (the rule above has to do with their /proc/pid entries, which are labeled with the domain of the associated process), file_type is for file types.
> > Is this process running within a vserver? dbusd can run as a system-wide message bus (as root) and as a per-session message bus (as the user who is logged in). In the latter situation, it cannot generate audit messages, and that is ok. Current versions of dbusd have been changed to not try generating audit messages in that case, IIUC. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel Gil Mayol <Daniel.Gil-Mayol_at_brunel.de> subject: Re: vserver and vprocunhide Date: Wed, 25 Oct 2006 10:33:18 +0200
But the "denied messages" I sent you before, are reported before I try to unhide the /proc/1.
> So, again, why are The problem is that I haven't programmed the vservers.
> > Oct 24 07:45:55 cnsu kernel: audit(1161675955.340:8577): avc: denied I just change the name, are the same.
> Where does this process run? On the "base" system or Do you mean vserver_ids? I think within each vserver.
> > Move init into its own domain means relabel /proc/1 with for example I wrote the following: domain_auto_trans(init_t, vserver_ids_exec_t, vserver_ids_t); and I am still receiving the same:
Oct 25 09:18:06 cnsu kernel: audit(1161767886.890:1510): avc: denied
{ search } for pid=3322 comm="pidof" name="1" dev=proc ino=65538
scontext=root:system_r:vserver_ids_t tcontext=user_u:system_r:unconfined_t
tclass=dir
> > I haven't found any definition of type init_t (something like "type Yes, each vserver is a daemon.
> But what about the rest of the processes running within each vserver Yes, httpd is shared for both vservers.
> > > And what was that assertion? Likely just requires an attribute on You are right, it is not a daemon....it is a simple script, I made a mistake using the macro daemon_domain().
> > > Is this process running within a vserver? The second "allow" was in my policy, I have added the first (audit_write) and I see the same message: Oct 25 07:57:27 cnsu dbus: Can't send to audit system: USER_AVC pid=26679 uid=81 loginuid=-1 message=avc: 0 AV entries and 0/512 buckets used, longestchain length 0 #--------------------------------------------------------------- I am trying to understand the "denied messages" to avoid to use allow with unconfined. For example the following:
Oct 25 08:02:37 cnsu kernel: audit(1161763357.211:1434): avc: denied
{ search } for pid=30655 comm="ls" name="util-vserver" dev=hda5 ino=208827
scontext=root:system_r:unconfined_t
Oct 25 08:02:37 cnsu kernel: audit(1161763357.239:1435): avc: denied { getattr } for pid=30655 comm="ls" name="vserver-wrapper" dev=hda5 ino=208979 scontext=root:system_r:unconfined_t tcontext=system_u:object_r:vserver_utils_t tclass=file In the first denied, ino=208827 is a node that, after execute "find / -inum 208827" I see that corresponds with the following directory: /usr/lib/util-vserver that is labelled with "system_u:object_r:vserver_utils_t", it is not unconfined. So, the denied message says the process with pid 30655 (that I don't know who is it because when I execute "ps -e | grep 30655" nothing appears) from the unconfined domain, executes "ls" over the directory "/usr/lib/util-vserver" and have not the rights to search in directories labelled with vserver_utils_t. Did I interpretate right the denied? What can I do to avoid this denied without write: allow unconfined_t vserver_utils_t:dir { search }; allow unconfined_t vserver_utils_t:file { getattr } Something that for me is strange is that the "find -inum NUMBER" sometimes reports me more than one files/directories for the same ino number, can that happen? Another thing that I don't understand is, why the unconfined domain ask for some new permissions like: allow unconfined_t crontab_exec_t:file getattr; I thought unconfined is free to do everything. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: vserver and vprocunhide Date: Wed, 25 Oct 2006 09:07:18 -0400
Then let's focus first on just addressing the avc messages, not on vprocunhide.
> > Where does this process run? On the "base" system or Are you sure? Please verify. What is its purpose? Why would you run an IDS within each vserver instance, where it can be compromised by a process within that vserver instance, vs. running it in the "host context" protected from the vserver instances aka "guests"?
> > No, you wouldn't relabel the /proc/1 files; you would define a domain That is a transition from init_t to vserver_ids_t upon executing a file labeled vserver_ids_exec_t. But nothing is yet running in init_t, so the rule achieves nothing by itself. Before playing with an init_t domain, let's just make sure we understand what is going on here and what is truly required. See my questions above about vserver_ids_t.
> and I am still receiving the same: Ok, so you know of at least one way to address this, by adding an allow rule and adjusting the neverallow rule to permit it. Another way is to not allow it but suppress the audit message via a dontaudit rule (same syntax as the allow rule); that is appropriate if the access is not truly required for the functioning of the vserver daemon.
> The second "allow" was in my policy, I have added the first (audit_write) and Ok, I'm not sure about the cause then. It isn't critical.
> I am trying to understand the "denied messages" to avoid to use allow with Allowing unconfined_t to do things is ok; it is supposed to be unrestricted (and usually this happens automatically when you use the right type attributes on any new types you define, like the "file_type" attribute for file types and the "domain" attribute for domains). Allowing other domains to access unconfined_t is the concern.
> Oct 25 08:02:37 cnsu kernel: audit(1161763357.211:1434): avc: denied If you install the "audit" package and run auditd, then you can also get syscall audit records with more information, like the full pathname. Note that when auditd is running, both the avc messages and the syscall audit records will be logged to /var/log/audit/audit.log instead of /var/log/messages.
> In the first denied, ino=208827 is a node that, after execute "find / -inum Yes.
> What can I do to avoid this denied without Declare vserver_utils_t as having the file_type attribute, and it will be automatically picked up by allow rules on that attribute. Or if you don't want to allow it and don't want to see audit messages about it, define dontaudit rules.
> Something that for me is strange is that the "find -inum NUMBER" sometimes Yes; inode numbers are per-filesystem. That is why the avc message also includes the dev= information.
> Another thing that I don't understand is, why the unconfined domain ask for SELinux has no intrinsic definition of unconfined, so everything must be explicitly allowed. But this is usually handled transparently by using type attributes, and then defining allow rules on those type attributes for unconfined_t such that it picks up access to everything with those attributes. So if you had defined crontab_exec_t as:
type crontab_exec_t, file_type;
type crontab_exec_t; typeattribute crontab_exec_t file_type;then the existing allow rule between unconfined_t and file_type would have picked up this access. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel Gil Mayol <Daniel.Gil-Mayol_at_brunel.de> subject: Re: vserver and vprocunhide Date: Thu, 26 Oct 2006 11:55:14 +0200
I was wrong, it doesn't run in each vserver. There are a vserver only for IDS called vserver_ids. So, vserver_ids_t runs only within the vserver 'vserver_ids'.
> That is a transition from init_t to vserver_ids_t upon executing a file -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |