Solaris Zones, just how seperated are they anyways?
So I'm looking into BSM Auditing on Solaris 9 and 10. Anyone noticed that there is something missing in Sun's great offering? Well yes, a nice way of collecting the audit logs would have been nice.
Some might say, Solaris 10 supports syslog! Which is a great improvement, until you realise that syslog truncates each entry at 1024 characters (which isnt THAT long if you have looked at the audit logs).
So what to do if you want to collect logs from several hundred of servers in various security zones? Sun suggested that with Solaris 10 you can run your services in a Zone and the auditing will then take place in the global zone and then you can make a few scripts to send your logs to a logserver using scp, thats a pretty good approach but at the place where I work we dont really like having to open for ssh to a logserver.. What other ideas can we come up with?
One could be, Solaris 10 on a host with a few network interfaces and a zone for each interface connected to each DMZ running a NFS-server, each server logs to the nfs-share and rotates the log every 5 mins. On the global Zone a cronscript checks with fuser if each file is being held by the auditd and if not decides to move it of the NFS-share into the global zone, the files cannot be deleted without breaking into the global zone of the logserver which shouldnt be accessible from the different DMZ's. Sounds pretty neat in my ears and quite cost effective without having to resort to buying a StorEdge 5310 with Compliance Archiving software for quite a couple of thousand dollars..
So Im quite happy wow what a nice idea.. I make a quick phonecall to a my Sun Contact and explains what Im thinking and he responds, Nice idea.... On paper..... Only problem is that you cant have seperate NFS-Servers running in different zones.. and then my mood just went south from there.. which brings me back to my headline..
How seperate are Zones anyways? How dependent are they upon eachother, they share kernel, for some reason they arent seperate enough to run nfs-servers in them, you cant have different system clocks in them, they share Shared Memory.. How much can we trust zones, if Sun themselves cant make their own protocols and services run within a Zone (they released the NFS-specs to the opensource world in -84 apparently), how likely is it that all 3rd Party vendors will succeed in writing Zone compliant software?
Dont get me wrong, I think Zones is a great leap forward but is it "separate" enough, I dont have enough competence to judge if it is or isnt, but from my point of view, perhaps they arent in the current form, maybe they will be in Solaris 11?
posted by It's Mr Gintonic to you! @ 12:35 PM
5 comments
5 Comments:
NFS server support is
definitely something that
we (Sun) are looking at
providing. As this is
implemented in the kernel
and not in user-space, it
needs to be virtualizaed since
every zone may have a
different authentication
method, NFSv4 domain name,
etc, etc.
What this means is that
while third-party kernel
frameworks would require
porting to become
zone-aware, applications
(which are the bulk of
ISV software) will run
as-is in non-global zones
with only a few exceptions
(those which reference
devices like /dev/kmem
directly, for example).
The issue with the system
clock is similar - that's
a kernel entity and the
customers we spoke with
while gathering requirements
didn't require this. What
Zones do support is
separate time zones which
tends to be far more useful
for consolidation purposes.
Please see our webpages
at
http://www.opensolaris.org/os/community/zones/
http://www.sun.com/bigadmin/content/zones/
My first impression of Solaris Zones was much like everyone else. . . WOW! Although Zones are a huge improvement on a simple chroot env (which was really the only thing close in the past), NFS would be a great benefit going forward.
another option for you might be using LWP and Perl to send a POST request containing your log file to a server available to all other servers. A simple CGI could process that POST request. Sun uses http over SSL for it's CST tool if I am not mistaken.
Actually it would be quite useful for software test purposes if there is a possibility to set a clock in a local zone to a different date than the actual sysdate.
A separate time zone is for a different purpose. It would be of great advance when test hardware would not have to be rebooted to get a different sysdate.
I agree different clocks would be great for test systems! I actually made a rfe request for it during the beta stages of zones but it wasnt important enough or something.
Post a Comment
<< Home