[refpolicy] kernel_corenetwork.te.in.patch

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://people.fedoraproject.org/~dwalsh/SELinux/F11/kernel_corenetwork.te.in.patch

Add definitions for 

afs_client, agentx, certmaster, dccm, festival, flash, ftps, kismet, kprop, munin, pingd, pki*, prelude, speech, streaming, virt

Add additional ports for dhcpc, snmp,  tor, whois

A range of ports for cyphesis, http_cache, vnc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmsXTwACgkQrlYvE4MpobMHoQCdEgijepdmVYuDq1M9K1jRUf/N
t1MAn0MRc/eOTnkXBMNtC3Nu1b+X5po3
=UZdw
-----END PGP SIGNATURE-----

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F11/kernel_corenetwork.te.in.patch

Lots of additional port interfaces.


Need aliases for node_t

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F11/kernel_corenetwork.te.in.patch

Lots of new port types and ports modifies to include addition port numbers.

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F12/kernel_corenetwork.te.in.patch

Lots of new ports.  For several domains, also split out the asterisk port 5060 to a sid port

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F13/kernel_corenetwork.te.in.patch

Still a few extra network ports although less then there used to be.

[refpolicy] kernel_corenetwork.te.in.patch

[Christopher J. PeBenito]

On Tue, 2010-02-23 at 16:34 -0500, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F13/kernel_corenetwork.te.in.patch
> 
> Still a few extra network ports although less then there used to be.

Merged the changes to existing ports now.  The new ports will be added
when the related change in the calling policy is merged.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_corenetwork.te.in.patch

tun_tap_device is an mls trusted object

Lots of new port definitions.

[refpolicy] kernel_corenetwork.te.in.patch

[Christopher J. PeBenito]

On Wed, 2010-06-02 at 16:18 -0400, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_corenetwork.te.in.patch
> 
> tun_tap_device is an mls trusted object

Why?  This seems wrong to me.

> Lots of new port definitions.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

On 06/04/2010 09:52 AM, Christopher J. PeBenito wrote:
> On Wed, 2010-06-02 at 16:18 -0400, Daniel J Walsh wrote:
>> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_corenetwork.te.in.patch
>>
>> tun_tap_device is an mls trusted object
>
> Why?  This seems wrong to me.
>
>> Lots of new port definitions.
>
I think virtual machines at different levels need to talk to this device.

[refpolicy] kernel_corenetwork.te.in.patch

[Christopher J. PeBenito]

On Fri, 2010-06-04 at 10:53 -0400, Daniel J Walsh wrote:
> On 06/04/2010 09:52 AM, Christopher J. PeBenito wrote:
> > On Wed, 2010-06-02 at 16:18 -0400, Daniel J Walsh wrote:
> >> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_corenetwork.te.in.patch
> >>
> >> tun_tap_device is an mls trusted object
> >
> > Why?  This seems wrong to me.

> I think virtual machines at different levels need to talk to this device.

But there are several of these devices.  Making it trusted means that
theres no separation between the networks, which seems contrary to what
a MLS system would want.  More likely, the MLS label needs to be changed
as needed.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] kernel_corenetwork.te.in.patch

[Daniel J Walsh]

On 06/04/2010 11:43 AM, Christopher J. PeBenito wrote:
> On Fri, 2010-06-04 at 10:53 -0400, Daniel J Walsh wrote:
>> On 06/04/2010 09:52 AM, Christopher J. PeBenito wrote:
>>> On Wed, 2010-06-02 at 16:18 -0400, Daniel J Walsh wrote:
>>>> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_corenetwork.te.in.patch
>>>>
>>>> tun_tap_device is an mls trusted object
>>>
>>> Why?  This seems wrong to me.
>
>> I think virtual machines at different levels need to talk to this device.
>
> But there are several of these devices.  Making it trusted means that
> theres no separation between the networks, which seems contrary to what
> a MLS system would want.  More likely, the MLS label needs to be changed
> as needed.
>
I think the kernel will take care of the isolation.

Eric Dan, Is tuntap device per qemu instance?

[refpolicy] kernel_corenetwork.te.in.patch

[Christopher J. PeBenito]

On Mon, 2010-06-07 at 10:30 +0100, Daniel P. Berrange wrote:
> On Fri, Jun 04, 2010 at 04:32:25PM -0400, Daniel J Walsh wrote:
> > On 06/04/2010 11:43 AM, Christopher J. PeBenito wrote:
> > >On Fri, 2010-06-04 at 10:53 -0400, Daniel J Walsh wrote:
> > >>On 06/04/2010 09:52 AM, Christopher J. PeBenito wrote:
> > >>>On Wed, 2010-06-02 at 16:18 -0400, Daniel J Walsh wrote:
> > >>>>http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_corenetwork.te.in.patch
> > >>>>
> > >>>>tun_tap_device is an mls trusted object
> > >>>
> > >>>Why?  This seems wrong to me.
> > >
> > >>I think virtual machines at different levels need to talk to this device.
> > >
> > >But there are several of these devices.  Making it trusted means that
> > >theres no separation between the networks, which seems contrary to what
> > >a MLS system would want.  More likely, the MLS label needs to be changed
> > >as needed.
> > >
> > I think the kernel will take care of the isolation.
> > 
> > Eric Dan, Is tuntap device per qemu instance?
> 
> Yes, every guest NIC gets associated with its own TAP device. libvirtd
> opens /dev/net/tun. This creates a new tap devices 'vnet0', 'vnet1',
> 'vnet2' etc. The file descriptor for each NIC's tap device is passed to
> the QEMU process when it starts, or using SCM_RIGHTS for NIC hotplug
> to an existing QEMU. 

This is my exact point.  You're trusting libvirtd to handle all that
correctly.  Nothing stops qemu from using the wrong device.  This just
reinforces my thinking that it is _not_ a trusted device.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com