Xen users - May 2005 - Is using w! safe to share data between domains?

I have a slightly unusual situation where I need to pass data from one
domain to another but, for security reasons, one of the domains will not
be on the network.  I would like to pass the data via a shared disk
partition.  I would like to know if what I have done is safe.

I created a disk partition named /dev/VG1/pkipass.
Each domU disk definition contains: ''phy:VG1/pkipass,sda3,w!''
None of the domUs automatically mounts this device.

When one domU needs to deposit data for another domU to pick up (this
exchange is always a manual effort to first deposit the shared data and
then retrieve the shared data), we do the following:

The depositing domU mounts sda3 read-only.
It looks for a tag file -- this tag file is created when a domU has
mounted the partition as read-write
If the tag-file exists {
	it unmounts the partition
	it sleeps briefly
	it retries
}
else {
	it remounts the partition read-write
	it creates the tag file
	it deposits the data
	it deletes the tag fie
	it unmounts the partition
}

A similar process is used to retrieve the data.

Is this safe?

Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

If you would like to participate in the development of an open source
enterprise class network security management system, please visit
http://iscs.sourceforge.net


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Your scheme has a race condition in it.  Suppose that a partition has 
opened sda3 read-only and right between after seeing the tag-file 
doesn''t exist and re-mounting the partition, someone else comes in and 
creates the tag file.  You know have to partitions that have followed 
your rules and have simultaneously opened the partition read-write.

Even if you eliminated the race condition, in general, it''s probably
not
a good idea to open a file system (even if it''s read-only) while
someone
else has it open read-write.  There''s no guarantee the meta-data is 
going to be in a consistent state.

Your best bet is probably to use networking to share data between 
partitions.

Regards,

Anthony Liguori
John A. Sullivan III wrote:
>I have a slightly unusual situation where I need to pass data from one
>domain to another but, for security reasons, one of the domains will not
>be on the network.  I would like to pass the data via a shared disk
>partition.  I would like to know if what I have done is safe.
>
>I created a disk partition named /dev/VG1/pkipass.
>Each domU disk definition contains:
''phy:VG1/pkipass,sda3,w!''
>None of the domUs automatically mounts this device.
>
>When one domU needs to deposit data for another domU to pick up (this
>exchange is always a manual effort to first deposit the shared data and
>then retrieve the shared data), we do the following:
>
>The depositing domU mounts sda3 read-only.
>It looks for a tag file -- this tag file is created when a domU has
>mounted the partition as read-write
>If the tag-file exists {
>	it unmounts the partition
>	it sleeps briefly
>	it retries
>}
>else {
>	it remounts the partition read-write
>	it creates the tag file
>	it deposits the data
>	it deletes the tag fie
>	it unmounts the partition
>}
>
>A similar process is used to retrieve the data.
>
>Is this safe?
>
>Thanks - John
>  
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Even if you eliminated the race condition, in general, it''s
probably not
> a good idea to open a file system (even if it''s read-only) while
someone
> else has it open read-write.  There''s no guarantee the meta-data
is
> going to be in a consistent state.
If you open a filesystem read only whilst there''s another writer, the
read
only domain will detect filesystem corruption and get upset.  It''s not 
inconceivable that the reader would actually crash but I haven''t
actually
heard of this happening.

Cheers,
Mark
> Your best bet is probably to use networking to share data between
> partitions.
>
> Regards,
>
> Anthony Liguori
>
> John A. Sullivan III wrote:
> >I have a slightly unusual situation where I need to pass data from one
> >domain to another but, for security reasons, one of the domains will
not
> >be on the network.  I would like to pass the data via a shared disk
> >partition.  I would like to know if what I have done is safe.
> >
> >I created a disk partition named /dev/VG1/pkipass.
> >Each domU disk definition contains:
''phy:VG1/pkipass,sda3,w!''
> >None of the domUs automatically mounts this device.
> >
> >When one domU needs to deposit data for another domU to pick up (this
> >exchange is always a manual effort to first deposit the shared data and
> >then retrieve the shared data), we do the following:
> >
> >The depositing domU mounts sda3 read-only.
> >It looks for a tag file -- this tag file is created when a domU has
> >mounted the partition as read-write
> >If the tag-file exists {
> >	it unmounts the partition
> >	it sleeps briefly
> >	it retries
> >}
> >else {
> >	it remounts the partition read-write
> >	it creates the tag file
> >	it deposits the data
> >	it deletes the tag fie
> >	it unmounts the partition
> >}
> >
> >A similar process is used to retrieve the data.
> >
> >Is this safe?
> >
> >Thanks - John
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Thursday 19 May 2005 10:37, John A. Sullivan III
wrote:
> I have a slightly unusual situation where I need to pass data from one
> domain to another but, for security reasons, one of the domains will not
> be on the network.  I would like to pass the data via a shared disk
> partition.  I would like to know if what I have done is safe.
Have you considered giving the networkless domain a vif but firewalling it off 
from everything you don''t trust?  Having network available would make
this
kind of sharing much easier, since you could use NFS (purely networked), GFS 
or OCFS2 (both disk-based but require a network component to work).

Cheers,
Mark
> I created a disk partition named /dev/VG1/pkipass.
> Each domU disk definition contains:
''phy:VG1/pkipass,sda3,w!''
> None of the domUs automatically mounts this device.
>
> When one domU needs to deposit data for another domU to pick up (this
> exchange is always a manual effort to first deposit the shared data and
> then retrieve the shared data), we do the following:
>
> The depositing domU mounts sda3 read-only.
> It looks for a tag file -- this tag file is created when a domU has
> mounted the partition as read-write
> If the tag-file exists {
> 	it unmounts the partition
> 	it sleeps briefly
> 	it retries
> }
> else {
> 	it remounts the partition read-write
> 	it creates the tag file
> 	it deposits the data
> 	it deletes the tag fie
> 	it unmounts the partition
> }
>
> A similar process is used to retrieve the data.
>
> Is this safe?
>
> Thanks - John
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Thu, 2005-05-19 at 16:21 +0100, Mark Williamson
wrote:
> On Thursday 19 May 2005 10:37, John A. Sullivan III wrote:
> > I have a slightly unusual situation where I need to pass data from one
> > domain to another but, for security reasons, one of the domains will
not
> > be on the network.  I would like to pass the data via a shared disk
> > partition.  I would like to know if what I have done is safe.
> 
> Have you considered giving the networkless domain a vif but firewalling it
off
> from everything you don''t trust?  Having network available would
make this
> kind of sharing much easier, since you could use NFS (purely networked),
GFS
> or OCFS2 (both disk-based but require a network component to work).
> 
<snip>
Yes, that was the second choice.  We are trying to protect our
Certificate Authorities as much as possible.  Thanks to everyone for
their help - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

If you would like to participate in the development of an open source
enterprise class network security management system, please visit
http://iscs.sourceforge.net


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

I suspect that in reality you''ll get away with periodically mounting
the
partition read-only, copying out the data you want, then unmounting it.
You can leave it mounted rw in the other domain the whole time.

Ian
> On Thu, 2005-05-19 at 16:21 +0100, Mark Williamson wrote:
> > On Thursday 19 May 2005 10:37, John A. Sullivan III wrote:
> > > I have a slightly unusual situation where I need to pass 
> data from 
> > > one domain to another but, for security reasons, one of 
> the domains 
> > > will not be on the network.  I would like to pass the data via a 
> > > shared disk partition.  I would like to know if what I 
> have done is safe.
> > 
> > Have you considered giving the networkless domain a vif but 
> > firewalling it off from everything you don''t trust?  Having
network
> > available would make this kind of sharing much easier, 
> since you could 
> > use NFS (purely networked), GFS or OCFS2 (both disk-based 
> but require a network component to work).
> > 
> <snip>
> Yes, that was the second choice.  We are trying to protect 
> our Certificate Authorities as much as possible.  Thanks to 
> everyone for their help - John
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan@opensourcedevel.com
> 
> If you would like to participate in the development of an 
> open source enterprise class network security management 
> system, please visit http://iscs.sourceforge.net
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hmmm . . . well, I really would prefer to do that although I was
suspicious of the race condition someone else pointed out.  The data
exchange is bidirectional.  That''s why, at some point, multiple devices
must mount it rw though none at the same time unless accidentally.

Should I assume that if one system was always rw and the other ro, that
I could get away with it but, if I must change back and forth, I asking
for trouble?

Thanks very much - and by the way, thanks for such a great product -
John

On Thu, 2005-05-19 at 18:47 +0100, Ian Pratt wrote:
> I suspect that in reality you''ll get away with periodically
mounting the
> partition read-only, copying out the data you want, then unmounting it.
> You can leave it mounted rw in the other domain the whole time.
> 
> Ian
> 
> > On Thu, 2005-05-19 at 16:21 +0100, Mark Williamson wrote:
> > > On Thursday 19 May 2005 10:37, John A. Sullivan III wrote:
> > > > I have a slightly unusual situation where I need to pass 
> > data from 
> > > > one domain to another but, for security reasons, one of 
> > the domains 
> > > > will not be on the network.  I would like to pass the data
via a
> > > > shared disk partition.  I would like to know if what I 
> > have done is safe.
> > > 
> > > Have you considered giving the networkless domain a vif but 
> > > firewalling it off from everything you don''t trust? 
Having network
> > > available would make this kind of sharing much easier, 
> > since you could 
> > > use NFS (purely networked), GFS or OCFS2 (both disk-based 
> > but require a network component to work).
> > > 
> > <snip>
> > Yes, that was the second choice.  We are trying to protect 
> > our Certificate Authorities as much as possible.  Thanks to 
> > everyone for their help - John
> > --
> > John A. Sullivan III
> > Open Source Development Corporation
> > +1 207-985-7880
> > jsullivan@opensourcedevel.com
> > 
> > If you would like to participate in the development of an 
> > open source enterprise class network security management 
> > system, please visit http://iscs.sourceforge.net
> > 
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> > 
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Hmmm . . . well, I really would prefer to do that although I 
> was suspicious of the race condition someone else pointed 
> out.  The data exchange is bidirectional.  That''s why, at 
> some point, multiple devices must mount it rw though none at 
> the same time unless accidentally.
> 
> Should I assume that if one system was always rw and the 
> other ro, that I could get away with it but, if I must change 
> back and forth, I asking for trouble?
Why not use two partitions, one domain ''owning'' each?

Alternatively, if you NTP sync the machines, you could co-ordinate when
they were going to mount the partition. This is a higher risk than the
alternative, though.

If you''ve only got one writer, the only risk is the reader''s
kernel
getting confused, but if you''ve just done a fresh mount of the file
system, read the data out and then unmount I suspect you''ll get away
with it in practice.

Ian

 
> Thanks very much - and by the way, thanks for such a great 
> product - John
> 
> On Thu, 2005-05-19 at 18:47 +0100, Ian Pratt wrote:
> > I suspect that in reality you''ll get away with periodically 
> mounting 
> > the partition read-only, copying out the data you want, 
> then unmounting it.
> > You can leave it mounted rw in the other domain the whole time.
> > 
> > Ian
> > 
> > > On Thu, 2005-05-19 at 16:21 +0100, Mark Williamson wrote:
> > > > On Thursday 19 May 2005 10:37, John A. Sullivan III wrote:
> > > > > I have a slightly unusual situation where I need to
pass
> > > data from
> > > > > one domain to another but, for security reasons, one of
> > > the domains
> > > > > will not be on the network.  I would like to pass the 
> data via a 
> > > > > shared disk partition.  I would like to know if what I
> > > have done is safe.
> > > > 
> > > > Have you considered giving the networkless domain a vif but 
> > > > firewalling it off from everything you don''t trust?
Having
> > > > network available would make this kind of sharing much
easier,
> > > since you could
> > > > use NFS (purely networked), GFS or OCFS2 (both disk-based
> > > but require a network component to work).
> > > > 
> > > <snip>
> > > Yes, that was the second choice.  We are trying to protect our 
> > > Certificate Authorities as much as possible.  Thanks to 
> everyone for 
> > > their help - John
> > > --
> > > John A. Sullivan III
> > > Open Source Development Corporation
> > > +1 207-985-7880
> > > jsullivan@opensourcedevel.com
> > > 
> > > If you would like to participate in the development of an open 
> > > source enterprise class network security management 
> system, please 
> > > visit http://iscs.sourceforge.net
> > > 
> > > 
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xensource.com
> > > http://lists.xensource.com/xen-users
> > > 
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan@opensourcedevel.com
> 
> Financially sustainable open source development 
> http://www.opensourcedevel.com
> 
> 
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Okay, heres what I''d like to have:

a 3G partition containg my BASE linux distro, and a client filebacked
distro such that if they make a change to /etc/somepkg.conf that file
gets saved in their linux.

That way any changes or updates I make to my BASE distro are propagated
to all, and yet their home dir and changes they make to files are kept
in their allocated space.  Would save greatly on spaced used for the O/S
too... I thought I read obout this a while back, but I can''t find it
now.

Hopefully this makes sense.

Thanks,
-- 
Jack Downes <jack@chainreactionweb.com>
Chain Reaction Web


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Am Donnerstag, den 19.05.2005, 05:37 -0400 schrieb John A. Sullivan
III: 
> I have a slightly unusual situation where I need to pass data from one
> domain to another but, for security reasons, one of the domains will not
> be on the network.  I would like to pass the data via a shared disk
> partition.  I would like to know if what I have done is safe.
UML has a neat & simple solution for sharing filesystems between the
guests and the host (that''s UML speak, read "between the domUs and
dom0"): hostfs. The host can assign a "hostfs-root-dir" to a
guest; the
guest may then mount any subdir of that directly into its own filesystem
(like a bindmount). Read/write operations get mapped to a uid on the
host (that mapping comes naturally since a UML guest is nothing but a
process on the host owned by that uid). Hostfs is really cool in
situations where nfs would be overkill or considered a security risk (i
admit: i do not know if hostfs actually _is_ more secure than nfs, or -
if not - if it could be designed in a secure manner. It just appears to
be more secure due to its simplicity).

Would such a thing be interesting for xen? Or would that be too evil? I
really missed hostfs when i switched from UML to xen.

/nils.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Nils Toedtmann wrote:
>Am Donnerstag, den 19.05.2005, 05:37 -0400 schrieb John A. Sullivan
>III: 
>  
>
>>I have a slightly unusual situation where I need to pass data from one
>>domain to another but, for security reasons, one of the domains will not
>>be on the network.  I would like to pass the data via a shared disk
>>partition.  I would like to know if what I have done is safe.
>>    
>>
>
>UML has a neat & simple solution for sharing filesystems between the
>guests and the host (that''s UML speak, read "between the domUs
and
>dom0"): hostfs. The host can assign a "hostfs-root-dir" to a
guest; the
>guest may then mount any subdir of that directly into its own filesystem
>(like a bindmount). Read/write operations get mapped to a uid on the
>host (that mapping comes naturally since a UML guest is nothing but a
>process on the host owned by that uid). Hostfs is really cool in
>situations where nfs would be overkill or considered a security risk (i
>admit: i do not know if hostfs actually _is_ more secure than nfs, or -
>if not - if it could be designed in a secure manner. It just appears to
>be more secure due to its simplicity).
>  
>
I don''t know how UML does this but it seems like VMware embeds a
version
of Samba for this purpose.

You could certainly use it to achieve the same goal.

Regards,

Anthony Liguori
>Would such a thing be interesting for xen? Or would that be too evil? I
>really missed hostfs when i switched from UML to xen.
>
>/nils.
>
>
>_______________________________________________
>Xen-users mailing list
>Xen-users@lists.xensource.com
>http://lists.xensource.com/xen-users
>
>  
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ah, perhaps I didn''t make something sufficiently clear.  Although
several domUs will have access to the partition, only one should have it
mounted at any time.  In other words, the system first mounts it read
only simply to check to see if anyone else has it mounted and, if they
do not, they remount it as rw.  There is the possibility that, in
between the check and the remount as rw, something could sneak in.  And
there is the brief moment when it is mounted ro that another device
could be writing to it in which case it is immediately unmounted.

Network exchange with a big firewall does sound technically safer from
corruption even if less safe from intrusion.  Thanks - John

On Thu, 2005-05-19 at 20:19 +0100, Ian Pratt wrote:
>  > Hmmm . . . well, I really would prefer to do that although I 
> > was suspicious of the race condition someone else pointed 
> > out.  The data exchange is bidirectional.  That''s why, at 
> > some point, multiple devices must mount it rw though none at 
> > the same time unless accidentally.
> > 
> > Should I assume that if one system was always rw and the 
> > other ro, that I could get away with it but, if I must change 
> > back and forth, I asking for trouble?
> 
> Why not use two partitions, one domain ''owning'' each?
> 
> Alternatively, if you NTP sync the machines, you could co-ordinate when
> they were going to mount the partition. This is a higher risk than the
> alternative, though.
> 
> If you''ve only got one writer, the only risk is the
reader''s kernel
> getting confused, but if you''ve just done a fresh mount of the
file
> system, read the data out and then unmount I suspect you''ll get
away
> with it in practice.
> 
> Ian
> 
>  
> > Thanks very much - and by the way, thanks for such a great 
> > product - John
> > 
> > On Thu, 2005-05-19 at 18:47 +0100, Ian Pratt wrote:
> > > I suspect that in reality you''ll get away with
periodically
> > mounting 
> > > the partition read-only, copying out the data you want, 
> > then unmounting it.
> > > You can leave it mounted rw in the other domain the whole time.
> > > 
> > > Ian
> > > 
> > > > On Thu, 2005-05-19 at 16:21 +0100, Mark Williamson wrote:
> > > > > On Thursday 19 May 2005 10:37, John A. Sullivan III
wrote:
> > > > > > I have a slightly unusual situation where I need
to pass
> > > > data from
> > > > > > one domain to another but, for security reasons,
one of
> > > > the domains
> > > > > > will not be on the network.  I would like to pass
the
> > data via a 
> > > > > > shared disk partition.  I would like to know if
what I
> > > > have done is safe.
> > > > > 
> > > > > Have you considered giving the networkless domain a vif
but
> > > > > firewalling it off from everything you don''t
trust?  Having
> > > > > network available would make this kind of sharing much
easier,
> > > > since you could
> > > > > use NFS (purely networked), GFS or OCFS2 (both
disk-based
> > > > but require a network component to work).
> > > > > 
> > > > <snip>
> > > > Yes, that was the second choice.  We are trying to protect
our
> > > > Certificate Authorities as much as possible.  Thanks to 
> > everyone for 
> > > > their help - John
> > > > --
> > > > John A. Sullivan III
> > > > Open Source Development Corporation
> > > > +1 207-985-7880
> > > > jsullivan@opensourcedevel.com
> > > > 
> > > > If you would like to participate in the development of an
open
> > > > source enterprise class network security management 
> > system, please 
> > > > visit http://iscs.sourceforge.net
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-users mailing list
> > > > Xen-users@lists.xensource.com
> > > > http://lists.xensource.com/xen-users
> > > > 
> > --
> > John A. Sullivan III
> > Open Source Development Corporation
> > +1 207-985-7880
> > jsullivan@opensourcedevel.com
> > 
> > Financially sustainable open source development 
> > http://www.opensourcedevel.com
> > 
> > 
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Am Donnerstag, den 19.05.2005, 18:34 -0500 schrieb Anthony Liguori:
> Nils Toedtmann wrote:
> >Am Donnerstag, den 19.05.2005, 05:37 -0400 schrieb John A. Sullivan
> >III: 
> >>I have a slightly unusual situation where I need to pass data from
one
> >>domain to another but, for security reasons, one of the domains
will not
> >>be on the network.  I would like to pass the data via a shared disk
> >>partition.  I would like to know if what I have done is safe.
> >
> >UML has a neat & simple solution for sharing filesystems between
the
> >guests and the host (that''s UML speak, read "between the
domUs and
> >dom0"): hostfs. The host can assign a "hostfs-root-dir"
to a guest; the
> >guest may then mount any subdir of that directly into its own
filesystem
> >(like a bindmount). Read/write operations get mapped to a uid on the
> >host (that mapping comes naturally since a UML guest is nothing but a
> >process on the host owned by that uid). Hostfs is really cool in
> >situations where nfs would be overkill or considered a security risk (i
> >admit: i do not know if hostfs actually _is_ more secure than nfs, or -
> >if not - if it could be designed in a secure manner. It just appears to
> >be more secure due to its simplicity).
> >  
> I don''t know how UML does this
It''s a guest kernel compile time option. Hostfs does not need any
userland tools/daemons.
> but it seems like VMware embeds a version of Samba for this purpose.
Yes it does.
> You could certainly use it to achieve the same goal.
Not if my goal is to avoid network filesystems or - like John - to avoid
networking at all! Hostfs is _much_ simpler (and more secure??) than nfs
or smbfs/cifs. nfs needs a portmapper daemon, a nfs-server, a lock-
daemon, uses dynamic port allocations which are hard to firewall,
authentication need to be configured properly; cifs/smbfs needs - at
least - a nmbd & smbd deamon, sid<-->uid mapping and authentication
need
to be configured properly ... And you do not want to export a unixish fs
to a unixish os via cifs ;)

btw: vmware has another functionality they call "shared folders". That
comes much closer to hostfs.

/nils.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Since the domains will keep the same time you could write your scripts
to do the following:

1. Figure out how long a domain will need the fs (for this example
we''ll use 4min).
2. Configure each domain to mount the fs ro and check for "tag-file"
file every other minutes (odd/even).
3. If domain 1 needs the file system it waits it''s turn then mounts
the fs ro, checks for the tag-file, remounts rw writes the tag-file,
unmounts the fs, sleeps 2 minutes .
4. Domain 2 mounts the fs ro check for the tag-file, finds it, unmount
the fs, and sleeps 7 minutes.
5. Domain 1 after waiting two minutes mounts the fs rw does it''s work,
deletes the tag-file, and unmounts the fs.

As long as the clocks stay in sync and processing completes in the
alloted time the two domains never mount the fs at the same time.

David


On 5/19/05, John A. Sullivan III <jsullivan@opensourcedevel.com>
wrote:
> Ah, perhaps I didn''t make something sufficiently clear.  Although
> several domUs will have access to the partition, only one should have it
> mounted at any time.  In other words, the system first mounts it read
> only simply to check to see if anyone else has it mounted and, if they
> do not, they remount it as rw.  There is the possibility that, in
> between the check and the remount as rw, something could sneak in.  And
> there is the brief moment when it is mounted ro that another device
> could be writing to it in which case it is immediately unmounted.
> 
> Network exchange with a big firewall does sound technically safer from
> corruption even if less safe from intrusion.  Thanks - John
> 
> On Thu, 2005-05-19 at 20:19 +0100, Ian Pratt wrote:
> >  > Hmmm . . . well, I really would prefer to do that although I
> > > was suspicious of the race condition someone else pointed
> > > out.  The data exchange is bidirectional.  That''s why,
at
> > > some point, multiple devices must mount it rw though none at
> > > the same time unless accidentally.
> > >
> > > Should I assume that if one system was always rw and the
> > > other ro, that I could get away with it but, if I must change
> > > back and forth, I asking for trouble?
> >
> > Why not use two partitions, one domain ''owning''
each?
> >
> > Alternatively, if you NTP sync the machines, you could co-ordinate
when
> > they were going to mount the partition. This is a higher risk than the
> > alternative, though.
> >
> > If you''ve only got one writer, the only risk is the
reader''s kernel
> > getting confused, but if you''ve just done a fresh mount of
the file
> > system, read the data out and then unmount I suspect you''ll
get away
> > with it in practice.
> >
> > Ian
> >
> >
> > > Thanks very much - and by the way, thanks for such a great
> > > product - John
> > >
> > > On Thu, 2005-05-19 at 18:47 +0100, Ian Pratt wrote:
> > > > I suspect that in reality you''ll get away with
periodically
> > > mounting
> > > > the partition read-only, copying out the data you want,
> > > then unmounting it.
> > > > You can leave it mounted rw in the other domain the whole
time.
> > > >
> > > > Ian
> > > >
> > > > > On Thu, 2005-05-19 at 16:21 +0100, Mark Williamson
wrote:
> > > > > > On Thursday 19 May 2005 10:37, John A. Sullivan
III wrote:
> > > > > > > I have a slightly unusual situation where I
need to pass
> > > > > data from
> > > > > > > one domain to another but, for security
reasons, one of
> > > > > the domains
> > > > > > > will not be on the network.  I would like to
pass the
> > > data via a
> > > > > > > shared disk partition.  I would like to know
if what I
> > > > > have done is safe.
> > > > > >
> > > > > > Have you considered giving the networkless domain
a vif but
> > > > > > firewalling it off from everything you
don''t trust?  Having
> > > > > > network available would make this kind of sharing
much easier,
> > > > > since you could
> > > > > > use NFS (purely networked), GFS or OCFS2 (both
disk-based
> > > > > but require a network component to work).
> > > > > >
> > > > > <snip>
> > > > > Yes, that was the second choice.  We are trying to
protect our
> > > > > Certificate Authorities as much as possible.  Thanks to
> > > everyone for
> > > > > their help - John
> > > > > --
> > > > > John A. Sullivan III
> > > > > Open Source Development Corporation
> > > > > +1 207-985-7880
> > > > > jsullivan@opensourcedevel.com
> > > > >
> > > > > If you would like to participate in the development of
an open
> > > > > source enterprise class network security management
> > > system, please
> > > > > visit http://iscs.sourceforge.net
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Xen-users mailing list
> > > > > Xen-users@lists.xensource.com
> > > > > http://lists.xensource.com/xen-users
> > > > >
> > > --
> > > John A. Sullivan III
> > > Open Source Development Corporation
> > > +1 207-985-7880
> > > jsullivan@opensourcedevel.com
> > >
> > > Financially sustainable open source development
> > > http://www.opensourcedevel.com
> > >
> > >
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan@opensourcedevel.com
> 
> Financially sustainable open source development
> http://www.opensourcedevel.com
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Am Donnerstag, den 19.05.2005, 19:49 -0400 schrieb John A. Sullivan
III:
> Ah, perhaps I didn''t make something sufficiently clear.  Although
> several domUs will have access to the partition, only one should have it
> mounted at any time.  In other words, the system first mounts it read
> only simply to check to see if anyone else has it mounted and, if they
> do not, they remount it as rw.  There is the possibility that, in
> between the check and the remount as rw, something could sneak in.  And
> there is the brief moment when it is mounted ro that another device
> could be writing to it in which case it is immediately unmounted.
> 
> Network exchange with a big firewall does sound technically safer from
> corruption even if less safe from intrusion.  Thanks - John
[...]
Do you want to protect the CA domU only from the outside world, or has
it to be protected from the other (networked, hence potentially r00ted)
domUs (with which the CA domU exchanges data), too?

In the latter case, the other domU could try to attack the filesystem
driver of the CA domU by writing malicious fs metadata (like currupt
inode tables/superblocks/whatever) to that partition. I''d consider a
nfs
relay between them safer!

And you could make firewalling much easier if you use a "virtual DMZ"
toppology (all interfaces marked with a * shall use private rfc1918 ip
addresses):

  evil internet 
        |
        |
    dom0-eth0
        |
        |xen-br0
        |
    dom1-eth0
  networked domU, maybe compromised, has to exchange data with dom3
    dom1-eth1*
        |
        |xen-br1 (has no ip in dom0)
        |
    dom2-eth0*
  nfs-server, no ip-forwarding
    dom2-eth1*
        |
        |xen-br2 (has no ip in dom0)
        |
    dom3-eth0*
  CA-domU

Even without any firewalling: to break into the CA domU, an attacker has
to overtake dom1, then the nfs-service on dom2 and finally the nfs-
client on dom3. 

I think it would be easier to attack the sshd on dom0 to compromise them
all ;)

/nils.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Nils Toedtmann wrote:
>>You could certainly use it to achieve the same goal.
>>    
>>
>
>Not if my goal is to avoid network filesystems or - like John - to avoid
>networking at all! Hostfs is _much_ simpler (and more secure??) than nfs
>  
>
Which is a perfectly reasonable goal.  Keep in mind however you do not 
have to expose a virtual network interface to the real network so you 
can think of a virtual network interfaces as just another interdomain 
communication mechanism.
>or smbfs/cifs. nfs needs a portmapper daemon, a nfs-server, a lock-
>daemon, uses dynamic port allocations which are hard to firewall,
>authentication need to be configured properly; cifs/smbfs needs - at
>least - a nmbd & smbd deamon, sid<-->uid mapping and
authentication need
>to be configured properly ... And you do not want to export a unixish fs
>to a unixish os via cifs ;)
>  
>
Actually, modern cifs clients provide unix extensions.  Also, you do not 
need most of the stuff you suggested.  The advantages of not having that 
much additional software running in dom0 is true.  However, a hostfs is 
a one-OS solution.  It requires significant engineering to extend to 
other platforms (like the BSD''s, Windows, etc.).  That''s
something to
consider.

There are cifs (and nfs) clients for Linux, Windows, *BSD, etc.  I''m
not
suggesting that this is the only solution but I certainly think it''s a 
useful one.
>btw: vmware has another functionality they call "shared folders".
That
>comes much closer to hostfs.
>  
>
Isn''t shared folders implemented with Samba?

Regards,

Anthony Liguori
>/nils.
>
>
>  
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Am Donnerstag, den 19.05.2005, 20:16 -0500 schrieb Anthony
Liguori:
> Nils Toedtmann wrote:
> > > You could certainly use it to achieve the same goal.
> >
> > Not if my goal is to avoid network filesystems or - like John - to
avoid
> > networking at all! Hostfs is _much_ simpler (and more secure??) than
nfs
> >
> Which is a perfectly reasonable goal.  Keep in mind however you do not 
> have to expose a virtual network interface to the real network so you 
> can think of a virtual network interfaces as just another interdomain 
> communication mechanism.
True. Some people just don''t feel well with running "bloated"
services
like samba (which have a well known history of security issues) when
there are simpler mechanisms.

> > or smbfs/cifs. nfs needs a portmapper daemon, a nfs-server, a lock-
> > daemon, uses dynamic port allocations which are hard to firewall,
> > authentication need to be configured properly; cifs/smbfs needs - at
> > least - a nmbd & smbd deamon, sid<-->uid mapping and
authentication need
> > to be configured properly ... And you do not want to export a unixish
fs
> > to a unixish os via cifs ;)
> >  
> >
> Actually, modern cifs clients provide unix extensions.  Also, you do not 
> need most of the stuff you suggested.  The advantages of not having that 
> much additional software running in dom0 is true. However, a hostfs is 
> a one-OS solution.  It requires significant engineering to extend to 
> other platforms (like the BSD''s, Windows, etc.).  That''s
something to
> consider.
True. That may be a no-go argument for a xen-implementation :-(

> There are cifs (and nfs) clients for Linux, Windows, *BSD, etc. 
I''m not
> suggesting that this is the only solution but I certainly think
it''s a
> useful one.
> 
> > btw: vmware has another functionality they call "shared
folders". That
> > comes much closer to hostfs.
> >  
> Isn''t shared folders implemented with Samba?
They appear to the guest as network drives, but they do not need a samba
service running on the host. File operations on the host are done by the
vmware process itself and underlie the fs permissions the vmware process
owner has. Maybe vmware internally translates that to cifs shares (using
samba code?).

/nils.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> > > Not if my goal is to avoid network filesystems or - like John -
to
> > > avoid networking at all! Hostfs is _much_ simpler (and more
secure??)
> > > than nfs
In comparison to almost any other Linux filesytem, HostFS is refreshingly 
simple.  It translates VFS ops into host filesystem operations in a rather 
direct way.

Unfortunately it wouldn''t be that neat under Xen because you''d
have to use a
"split" (i.e. front and back ends) driver.  The closest thing you
could get
to HostFS in terms of functionality and simplicity would probably be as 
follows:
* "XenHostFS" driver in the guest translates VFS operations to some 
OS-independent format and queues them in an interdomain comms ring
* "XenHostFSd" server in dom0 gets these and translates them into
local file
operations.  This could probably be implemented in userspace if you
weren''t
too worried about cunning performance tricks.
> > Actually, modern cifs clients provide unix extensions.  Also, you do
not
> > need most of the stuff you suggested.  The advantages of not having
that
> > much additional software running in dom0 is true. However, a hostfs is
> > a one-OS solution.  It requires significant engineering to extend to
> > other platforms (like the BSD''s, Windows, etc.). 
That''s something to
> > consider.
>
> True. That may be a no-go argument for a xen-implementation :-(
If the interdomain protocol is well defined then the above implementation 
could be made to work, although each OS would need a different frontend 
filesystem driver.
> They appear to the guest as network drives, but they do not need a samba
> service running on the host. File operations on the host are done by the
> vmware process itself and underlie the fs permissions the vmware process
> owner has. Maybe vmware internally translates that to cifs shares (using
> samba code?).
Ah yes, I think VMWare has an integrated virtual SMB server...  Scary! :-)

Cheers,
Mark
>
> /nils.
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Would such a thing be interesting for xen? Or would that be too evil? I
> really missed hostfs when i switched from UML to xen.
As I mentioned in my other e-mail, it would be possible to implement a fairly 
close approximation to hostfs under Xen.

I''m actually working on a Xen shared filesystem (although I''m
currently
distracted with other work).  This is intended as a replacement for NFS but 
implemented in a way which is highly optimised for a intra-machine sharing 
under Xen.  This will make a substantially more complex implementation but 
should give way better performance and resource usage.

A prototype implementation will be announced on the list when it''s
ready :-)

Cheers,
Mark

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 5/20/05, Mark Williamson <mark.williamson@cl.cam.ac.uk>
wrote:
> > Would such a thing be interesting for xen? Or would that be too evil?
I
> > really missed hostfs when i switched from UML to xen.
> 
> As I mentioned in my other e-mail, it would be possible to implement a
fairly
> close approximation to hostfs under Xen.
> 
> I''m actually working on a Xen shared filesystem (although
I''m currently
> distracted with other work).  This is intended as a replacement for NFS but
> implemented in a way which is highly optimised for a intra-machine sharing
> under Xen.  This will make a substantially more complex implementation but
> should give way better performance and resource usage.
> 
> A prototype implementation will be announced on the list when it''s
ready :-)
cant wait to try XenFS, Mark ;-)

regards,
aq

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Am Freitag, den 20.05.2005, 15:37 +0900 schrieb aq:
> On 5/20/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> > > Would such a thing be interesting for xen? Or would that be too
evil? I
> > > really missed hostfs when i switched from UML to xen.
> > 
> > As I mentioned in my other e-mail, it would be possible to implement a
fairly
> > close approximation to hostfs under Xen.
> > 
> > I''m actually working on a Xen shared filesystem (although
I''m currently
> > distracted with other work).  This is intended as a replacement for
NFS but
> > implemented in a way which is highly optimised for a intra-machine
sharing
> > under Xen.  This will make a substantially more complex implementation
but
> > should give way better performance and resource usage.
> > 
> > A prototype implementation will be announced on the list when
it''s ready :-)
> 
> cant wait to try XenFS, Mark ;-)
Did i already mention that i love the xen team ;) ?

/nils.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 5/19/05, Nils Toedtmann <xen-users@nils.toedtmann.net>
wrote:
> Am Donnerstag, den 19.05.2005, 19:49 -0400 schrieb John A. Sullivan III:
> > Ah, perhaps I didn''t make something sufficiently clear. 
Although
> > several domUs will have access to the partition, only one should have
it
> > mounted at any time.  In other words, the system first mounts it read
> > only simply to check to see if anyone else has it mounted and, if they
> > do not, they remount it as rw.  There is the possibility that, in
> > between the check and the remount as rw, something could sneak in. 
And
> > there is the brief moment when it is mounted ro that another device
> > could be writing to it in which case it is immediately unmounted.
> >
> > Network exchange with a big firewall does sound technically safer from
> > corruption even if less safe from intrusion.  Thanks - John
> [...]
> Do you want to protect the CA domU only from the outside world, or has
> it to be protected from the other (networked, hence potentially r00ted)
> domUs (with which the CA domU exchanges data), too?
> 
> In the latter case, the other domU could try to attack the filesystem
> driver of the CA domU by writing malicious fs metadata (like currupt
> inode tables/superblocks/whatever) to that partition. I''d consider
a nfs
> relay between them safer!
> 
> And you could make firewalling much easier if you use a "virtual
DMZ"
> toppology (all interfaces marked with a * shall use private rfc1918 ip
> addresses):
> 
>   evil internet
>         |
>         |
>     dom0-eth0
>         |
>         |xen-br0
>         |
>     dom1-eth0
>   networked domU, maybe compromised, has to exchange data with dom3
>     dom1-eth1*
>         |
>         |xen-br1 (has no ip in dom0)
>         |
>     dom2-eth0*
>   nfs-server, no ip-forwarding
>     dom2-eth1*
>         |
>         |xen-br2 (has no ip in dom0)
>         |
>     dom3-eth0*
>   CA-domU
> 
> Even without any firewalling: to break into the CA domU, an attacker has
> to overtake dom1, then the nfs-service on dom2 and finally the nfs-
> client on dom3.
> 
> I think it would be easier to attack the sshd on dom0 to compromise them
> all ;)
> 
> /nils.
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
Excuse my lack of knowledge, but I believe there is another
way to get to the thing done.

You want:

1) A number o domUs to write files to a place;
2) Make sure to have the most secure way to do it.

What if...

You set up a one bridge without IP number {
  brctl addbr xen-sw1
  brctl stp xen-sw1 off
  brctl setfd xen-sw1 0
  sleep 3
  ifconfig xen-sw1 up
}

Then you config your domUs to connect to the bridge,
each one implementing a RFC 1918 ip number and
same network for all of them. You see, any one can
see the other, but no one can reach dom0 or the LAN.

Now you configure a vsftpd to allow just one connection
at any time. You will NOT have more then one domU
accessing that file, for sure. And you enhance the security
with all features on vsftpd you can, so making it very 
restricted.

And you configure a firewall on each domU, accepting
NO input/forward on the ethernet connected to the 
bridged. Except for the domU where you have vsftpd,
which can be opened ONLY for ftpclients.

Is that good?
-- 
Bye,
Fernando Maior
LPIC/1 31908

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 5/20/05, Fernando Maior <fernando.souto.maior@gmail.com>
wrote:
> On 5/19/05, Nils Toedtmann <xen-users@nils.toedtmann.net> wrote:
> > Am Donnerstag, den 19.05.2005, 19:49 -0400 schrieb John A. Sullivan
III:
> > > Ah, perhaps I didn''t make something sufficiently clear. 
Although
> > > several domUs will have access to the partition, only one should
have it
> > > mounted at any time.  In other words, the system first mounts it
read
> > > only simply to check to see if anyone else has it mounted and, if
they
> > > do not, they remount it as rw.  There is the possibility that, in
> > > between the check and the remount as rw, something could sneak
in.  And
> > > there is the brief moment when it is mounted ro that another
device
> > > could be writing to it in which case it is immediately unmounted.
> > >
> > > Network exchange with a big firewall does sound technically safer
from
> > > corruption even if less safe from intrusion.  Thanks - John
> > [...]
> > Do you want to protect the CA domU only from the outside world, or has
> > it to be protected from the other (networked, hence potentially
r00ted)
> > domUs (with which the CA domU exchanges data), too?
> >
> > In the latter case, the other domU could try to attack the filesystem
> > driver of the CA domU by writing malicious fs metadata (like currupt
> > inode tables/superblocks/whatever) to that partition. I''d
consider a nfs
> > relay between them safer!
> >
> > And you could make firewalling much easier if you use a "virtual
DMZ"
> > toppology (all interfaces marked with a * shall use private rfc1918 ip
> > addresses):
> >
> >   evil internet
> >         |
> >         |
> >     dom0-eth0
> >         |
> >         |xen-br0
> >         |
> >     dom1-eth0
> >   networked domU, maybe compromised, has to exchange data with dom3
> >     dom1-eth1*
> >         |
> >         |xen-br1 (has no ip in dom0)
> >         |
> >     dom2-eth0*
> >   nfs-server, no ip-forwarding
> >     dom2-eth1*
> >         |
> >         |xen-br2 (has no ip in dom0)
> >         |
> >     dom3-eth0*
> >   CA-domU
> >
> > Even without any firewalling: to break into the CA domU, an attacker
has
> > to overtake dom1, then the nfs-service on dom2 and finally the nfs-
> > client on dom3.
> >
> > I think it would be easier to attack the sshd on dom0 to compromise
them
> > all ;)
> >
> > /nils.
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
> 
> Excuse my lack of knowledge, but I believe there is another
> way to get to the thing done.
> 
> You want:
> 
> 1) A number o domUs to write files to a place;
> 2) Make sure to have the most secure way to do it.
> 
> What if...
> 
> You set up a one bridge without IP number {
>   brctl addbr xen-sw1
>   brctl stp xen-sw1 off
>   brctl setfd xen-sw1 0
>   sleep 3
>   ifconfig xen-sw1 up
> }
> 
> Then you config your domUs to connect to the bridge,
> each one implementing a RFC 1918 ip number and
> same network for all of them. You see, any one can
> see the other, but no one can reach dom0 or the LAN.
> 
> Now you configure a vsftpd to allow just one connection
> at any time. You will NOT have more then one domU
> accessing that file, for sure. And you enhance the security
> with all features on vsftpd you can, so making it very
> restricted.
> 
> And you configure a firewall on each domU, accepting
> NO input/forward on the ethernet connected to the
> bridged. Except for the domU where you have vsftpd,
> which can be opened ONLY for ftpclients.
> 
> Is that good?
> --
> Bye,
> Fernando Maior
> LPIC/1 31908
> 
To enhance security on domUs that are ftpclients, you can
make iptables filter out any packets not related to the
domU that is the ftpserver.

-- 
Bye,
Fernando Maior
LPIC/1 31908

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users