From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: "Neugebauer, Rolf" <rolf.neugebauer@intel.com>
Cc: Mark Williamson <maw48@hermes.cam.ac.uk>,
xen-devel@lists.sourceforge.net, SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: [Xen-devel] protecting xen startup
Date: Wed, 24 Nov 2004 15:24:02 +0000 [thread overview]
Message-ID: <20041124152402.GQ5146@lkcl.net> (raw)
In-Reply-To: <39CC97884CA19A4D8D6296FE94357BCBF5CCD7@swsmsx404>
On Wed, Nov 24, 2004 at 11:48:15AM -0000, Neugebauer, Rolf wrote:
> Yes, in principle you should be able to do that (and we have been
> thinking along similar lines). However, at the moment the linux kernel
> in the exporting VM (BE) does not know anything about other VMs so as
> far as my understanding goes you can't apply SELinux policies to it as
> you don't have a subject.
okay.
that can be dealt with by... (this is speculation, here!)
by writing an selinux policy in advance that defines how many
virtual machines you have, and creating xen_vm0_t, xen_vm1_t
etc. to represent them.
you then define what operations can be carried out, and then
grant a program the right to perform that operation on SPECIFIC
machines. [yes there is a short-hand which allows you to specify an
operation be allowed by a program on all machines].
then it would be necessary to modify the linux kernel to call the
avc_has_perm() function at the appropriate point to check, at the time
that an operation was being done (e.g. read from block device), as to
whether that process had the right to perform that operation on that
xen virtual machine.
in order for this to work, it would be necessary to have a translation
mechanism between the numbering xen_vm_0_t etc. and the actual xen
virtual machines.
looking at avc_has_perm(), you'd need a SID per virtual machine,
as the second argument...
xen_communication_has_perm(struct task_struct *tsk,
struct xen_info *xen,
u32 perms)
{
return avc_has_perm(tsec->sid,
xen->sid, SECCLASS_XEN, perms, NULL, NULL);
}
where xen->sid contains "xen_vm_0_t", "xen_vm_1_t" etc.
and tsec->sid contains "xen_xm_bin_t" - representing the xen control
binary /usr/bin/xm.
the question i can't answer (the bit that i don't quite grok) is
how do you get hold of the right xen_info struct and how do you blat
the sid into it?
l.
--
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.
WARNING: multiple messages have this Message-ID (diff)
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: "Neugebauer, Rolf" <rolf.neugebauer@intel.com>
Cc: Mark Williamson <maw48@hermes.cam.ac.uk>,
xen-devel@lists.sourceforge.net, SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: protecting xen startup
Date: Wed, 24 Nov 2004 15:24:02 +0000 [thread overview]
Message-ID: <20041124152402.GQ5146@lkcl.net> (raw)
In-Reply-To: <39CC97884CA19A4D8D6296FE94357BCBF5CCD7@swsmsx404>
On Wed, Nov 24, 2004 at 11:48:15AM -0000, Neugebauer, Rolf wrote:
> Yes, in principle you should be able to do that (and we have been
> thinking along similar lines). However, at the moment the linux kernel
> in the exporting VM (BE) does not know anything about other VMs so as
> far as my understanding goes you can't apply SELinux policies to it as
> you don't have a subject.
okay.
that can be dealt with by... (this is speculation, here!)
by writing an selinux policy in advance that defines how many
virtual machines you have, and creating xen_vm0_t, xen_vm1_t
etc. to represent them.
you then define what operations can be carried out, and then
grant a program the right to perform that operation on SPECIFIC
machines. [yes there is a short-hand which allows you to specify an
operation be allowed by a program on all machines].
then it would be necessary to modify the linux kernel to call the
avc_has_perm() function at the appropriate point to check, at the time
that an operation was being done (e.g. read from block device), as to
whether that process had the right to perform that operation on that
xen virtual machine.
in order for this to work, it would be necessary to have a translation
mechanism between the numbering xen_vm_0_t etc. and the actual xen
virtual machines.
looking at avc_has_perm(), you'd need a SID per virtual machine,
as the second argument...
xen_communication_has_perm(struct task_struct *tsk,
struct xen_info *xen,
u32 perms)
{
return avc_has_perm(tsec->sid,
xen->sid, SECCLASS_XEN, perms, NULL, NULL);
}
where xen->sid contains "xen_vm_0_t", "xen_vm_1_t" etc.
and tsec->sid contains "xen_xm_bin_t" - representing the xen control
binary /usr/bin/xm.
the question i can't answer (the bit that i don't quite grok) is
how do you get hold of the right xen_info struct and how do you blat
the sid into it?
l.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
next prev parent reply other threads:[~2004-11-24 15:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-24 11:48 protecting xen startup Neugebauer, Rolf
2004-11-24 15:24 ` Luke Kenneth Casson Leighton [this message]
2004-11-24 15:24 ` Luke Kenneth Casson Leighton
2004-11-24 20:24 ` [Xen-devel] " Luke Kenneth Casson Leighton
2004-11-24 20:24 ` Luke Kenneth Casson Leighton
-- strict thread matches above, loose matches on Subject: below --
2004-11-23 17:05 Luke Kenneth Casson Leighton
2004-11-23 18:07 ` Mark Williamson
2004-11-23 20:51 ` Luke Kenneth Casson Leighton
2004-11-23 22:49 ` Mark Williamson
2004-11-24 0:18 ` [Xen-devel] " Luke Kenneth Casson Leighton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041124152402.GQ5146@lkcl.net \
--to=lkcl@lkcl.net \
--cc=maw48@hermes.cam.ac.uk \
--cc=rolf.neugebauer@intel.com \
--cc=selinux@tycho.nsa.gov \
--cc=xen-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.