WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [patch 5/5] xen: net features

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: [patch 5/5] xen: net features
From: Nuutti Kotivuori <naked@xxxxxx>
Date: Tue, 01 Feb 2005 14:53:10 +0200
Cache-post-path: aka.i.naked.iki.fi!unknown@xxxxxxxxxxxxxxxxxx
Cancel-lock: sha1:biHz973AEA9F0kTQoURatlZmU9I=
Delivery-date: Tue, 01 Feb 2005 12:58:05 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: Ye 'Ol Disorganized NNTPCache groupie
References: <A95E2296287EAD4EB592B5DEEFCE0E9D123619@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050201003121.GP2144@xxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux)
Jody Belka wrote:
> On Tue, Feb 01, 2005 at 12:00:17AM -0000, Ian Pratt wrote:
>>>> I can't see why making the frontend MAC readonly can really be
>>>> done securely within the domain.
>>>
>>> Well, if you have module support enabled in the kernel, or some
>>> way that lets root write to random (domain) memory, then it's not
>>> really secure, although i think it's still a nice to
>>> have. Otherwise i would think it should be reasonably secure?
>>
>> You need root access to change the mac normally, and its trivial
>> for root to change it under your scheme -- running sed on /dev/mem
>> would do it...
>
> I was thinking of something along the lines of adding a tiny bit of
> code to remove the CAP_SYS_MODULE and CAP_SYS_RAWIO capabilities
> from the global set of allowed cap's when using the readonly
> option. With that in place you're down to requiring a kernel-hole to
> get around it.

You would also need to disallow raw packet sockets on the ethernet
layer. Oh and ebtables / bridging, possibly some modules for iptables,
too. And probably a bunch of other things that allow generation of
packets with differing MAC addresses.

If something like this were to be implemented, I think it should be
implemented kernel wide for all network drivers - and it will require
always some additional in-kernel security model, which makes sure that
not even the root user is allowed to do certain things.

Otherwise it is indeed just a false sense of security.

With Xen, the vastly superior alternative is to enforce the MAC
address at the netback side, or in domain0 - because then the policy
is enforced even if the domain in question is totally compromised.

-- Naked



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel