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
|
Home