Xen users - Apr 2006 - XenAccess Library: Introspection for Xen

I''m pleased to announce a new project called XenAccess.  The project  
goals are to provide a full featured introspection library for Xen.   
Introspection is a technique where applications in one domain can  
view memory from another domain.  For example, you can run an  
application in dom0 to list the processes or LKMs in a domU.  More  
information is available on the website:

http://xenaccess.sourceforge.net/

Introspection has been discussed for a few years in the research  
community.  I''m hoping that this open source project will allow more  
people to play with it and start thinking about interesting  
applications for it.  And, of course, I''d be happy to see others  
interested in introspection get involved with this project as well!

Cheers,
bryan


-
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org





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

> I''m pleased to announce a new project called XenAccess.  The
project
> goals are to provide a full featured introspection library for Xen.
> Introspection is a technique where applications in one domain can
> view memory from another domain.  For example, you can run an
> application in dom0 to list the processes or LKMs in a domU.  More
> information is available on the website:
Sounds like a great idea.

I can see this being useful for IDS, for system monitoring, live problem 
diagnosis (e.g. trying to figure out what''s going on in a machine
that''s
become unresponsive), etc.

Eventually you could extend this with the ability to interpose on disk / 
network IO using the tap drivers (these are a bit out of date at the moment, 
but I understand Andy is intending to work on them again at some point).
> Introspection has been discussed for a few years in the research
> community.  I''m hoping that this open source project will allow
more
> people to play with it and start thinking about interesting
> applications for it.  And, of course, I''d be happy to see others
> interested in introspection get involved with this project as well!
>
It would be very nice to see Open Source IDS solutions based on this.  Had you 
considered porting an existing in-host IDS to use your introspection library 
to monitor another domain instead?

Actually, we can achieve several levels of monitoring now if we want:
1) IDS within a domain, either or both user and kernelspace.
2) IDS based on introspection in another domain on the same system.
3) IDS monitoring network traffic, either or both on the same system, or 
another host on the network.

Another thing I''ve been thinking would be neat is to feed all this data
(in
some standard format) into an IDS aggregator.  I''ve heard of such
things, I
think, but I don''t know what the current state of the art is.  It
should be
possible to get quite accurate pinpointing and diagnosis of both virtualised 
and non-virtualised servers across an enterprise this way.

Good luck with your work, anyhow!

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

> Sounds like a great idea.
Thanks :-)
> I can see this being useful for IDS, for system monitoring, live  
> problem
> diagnosis (e.g. trying to figure out what''s going on in a machine
> that''s
> become unresponsive), etc.
>
> Eventually you could extend this with the ability to interpose on  
> disk /
> network IO using the tap drivers (these are a bit out of date at  
> the moment,
> but I understand Andy is intending to work on them again at some  
> point).
Yes, all good ideas.  My primary interest in introspection is in the  
potential for developing new and interesting security applications.   
IDS / monitoring applications, as you mentioned, fit in very nicely  
here.  So do intrusion response applications since you are sitting in  
a powerful position to control and modify the domain in question.

Other uses that I''ve imagined include system management and  
debugging.  In fact, I''ve already used it on several occasions for  
simple kernel debugging (e.g., viewing the contents of a kernel data  
structure).  And I''m sure that there''s plenty more that I
haven''t
thought of yet as well.
> It would be very nice to see Open Source IDS solutions based on  
> this.  Had you
> considered porting an existing in-host IDS to use your  
> introspection library
> to monitor another domain instead?
Yes, I think that this would be great.  My focus right now will be on  
further development of XenAccess.  But, as time permits, I would be  
interested in looking into that and/or supporting others that want to  
use XenAccess for that purpose.

The other thing to consider is non-traditional host-based IDS.   
Through introspection, you need not be limited by the presentation of  
information that you normally get inside the operating system.   
Perhaps viewing memory "through a different lens" could lead to some  
interesting new techniques?  Something to think about.
> Actually, we can achieve several levels of monitoring now if we want:
> 1) IDS within a domain, either or both user and kernelspace.
> 2) IDS based on introspection in another domain on the same system.
> 3) IDS monitoring network traffic, either or both on the same  
> system, or
> another host on the network.
>
> Another thing I''ve been thinking would be neat is to feed all this
> data (in
> some standard format) into an IDS aggregator.  I''ve heard of such
> things, I
> think, but I don''t know what the current state of the art is.  It
> should be
> possible to get quite accurate pinpointing and diagnosis of both  
> virtualised
> and non-virtualised servers across an enterprise this way.
Indeed.  And, in addition to data aggregation, comparing the data  
from in the host to data from introspection to data on the network  
could lead to some interesting analysis.  For example, what if you  
saw conflicting information about the same system from two sensor  
locations?  Perhaps you just detected stealthy malware?

I''m excited about the possibilities.  Within the XenAccess project,  
I''m looking forward to collecting more data (including the driver  
taps that you mentioned and cpu context information), and adding more  
features such as instruction-level replay of a domain''s execution  
environment.  So keep watching and hopefully there will be some more  
interesting stuff coming down the pipe.

Cheers,
bryan


-
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org





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

> The other thing to consider is non-traditional host-based IDS.
> Through introspection, you need not be limited by the presentation of
> information that you normally get inside the operating system.
> Perhaps viewing memory "through a different lens" could lead to
some
> interesting new techniques?  Something to think about.
I think it''ll enable lots of things - we need to throw away our
preconceptions
to get the best out of the architecture.  So much more is possible without 
the constraints of just running inside / outside machine boundary of the 
monitored system.
> Indeed.  And, in addition to data aggregation, comparing the data
> from in the host to data from introspection to data on the network
> could lead to some interesting analysis.  For example, what if you
> saw conflicting information about the same system from two sensor
> locations?  Perhaps you just detected stealthy malware?
Indeed.  It''s going to need a fairly interesting inference engine to
figure
stuff out (and explain its decisions to administrators afterwards!).  Could 
be quite a cool project, depending on how much groundwork for this sort of 
thing already exists.
> I''m excited about the possibilities.  Within the XenAccess
project,
> I''m looking forward to collecting more data (including the driver
> taps that you mentioned and cpu context information), and adding more
> features such as instruction-level replay of a domain''s execution
> environment.  So keep watching and hopefully there will be some more
> interesting stuff coming down the pipe.
Just a heads-up that some people have been looking at deterministic replay, so 
you might want to figure out who they are and see what stage they''re
at.

A filter-style interface for collecting selected events from Xen (as proposed 
by Stanford guys in the introspection paper) would be a nice thing to have 
too.  Stuff like direct syscall monitoring could be implemented this way, for 
instance.

Sounds like you''ve got a whole load of good plans, anyhow.  I wish you
luck!

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

> I''m pleased to announce a new project called XenAccess.  The
project
> goals are to provide a full featured introspection library for Xen.   
> Introspection is a technique where applications in one domain can  
> view memory from another domain.  For example, you can run an  
> application in dom0 to list the processes or LKMs in a domU.  More  
> information is available on the website:
> 
> http://xenaccess.sourceforge.net/
> 
> Introspection has been discussed for a few years in the research  
> community.  I''m hoping that this open source project will allow
more
> people to play with it and start thinking about interesting  
> applications for it.  And, of course, I''d be happy to see others  
> interested in introspection get involved with this project as well!
> 
> Cheers,
> bryan
I''m interested in introspection for both Linux and Windows; let me ask
a few
naïve questions about potential capabilities:

Would XenAccess implementation and functionality be the same for both
paravirtualized and fully virtualized (using VT) guests?

Would the only difference between introspection on a Linux vs Windows guest
be the closed and undocumented nature of the Windows kernel?

How difficult would it be to get a look at a running guest''s file
system?
Linux seems easy, but I believe Windows guests use vmx images; can the
Windows file system be viewed naturally from the outside?

Are there any other potential obstacles or difficulties that would make
various introspection techniques on Windows impossible, difficult, or merely
a nuisance?

Thanks for any thoughts,

Steve Brueckner, ATC-NY

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

> Would XenAccess implementation and functionality be the same for both
> paravirtualized and fully virtualized (using VT) guests?
I imagine that the changes for VT guests would range somewhere from  
none to minimal.  However, I haven''t actually used XenAccess on VT  
hardware yet, so I can''t say for sure.  If you try it out, please let  
me know what you find.
> Would the only difference between introspection on a Linux vs  
> Windows guest
> be the closed and undocumented nature of the Windows kernel?
Pretty much.  The nice thing is that memory access is more hardware  
dependent than OS dependent.  Therefore, you should be able to access  
virtual addresses on windows just like you can on linux.  The trick  
is knowing which address to access :-)  On linux you can leverage the  
source code, system map file, etc to see how things are laid out in  
memory.  On windows, it''s going to be a little tricker to figure out  
which addresses to access.

I''m more knowledgeable with linux than I am with windows.  So perhaps  
there''s some information out there that I''m not aware of that
would
help with this situation.  But, even without extra information, one  
should be able to discern quite a bit of information through reverse  
engineering techniques.
> How difficult would it be to get a look at a running guest''s file
> system?
> Linux seems easy, but I believe Windows guests use vmx images; can the
> Windows file system be viewed naturally from the outside?
Having not used VT hardware, I''m not familiar with the vmx image  
files.  But, assuming that the format is well known, you should be  
able to access its contents from dom0.  Another option is to tap the  
device access between the frontend and backend drivers, which would  
allow you to view data as it is being accessed.
> Are there any other potential obstacles or difficulties that would  
> make
> various introspection techniques on Windows impossible, difficult,  
> or merely
> a nuisance?
I believe that introspection with Windows should be very doable.  In  
fact, if you look at the XenAccess source code, you''ll see that
I''ve
already started breaking out OS-specific code.  My plan is to work on  
support for other OSes once linux is up and running.  Of course, if  
you have any success with windows first, I''d be happy to integrate  
the code into subversion.

If you have other questions, feel free to drop me a line and/or post  
to the XenAccess mailing list.

Cheers,
bryan


-
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org





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