Paul Roberts' Musings

Friday July 11, 2008

Limiting the size of the auditing log

Versions of Solaris up to and including Solaris 9 provide a nice feature within the auditing subsystem by which an upper limit can be defined for the size of the auditing log. Once this is reached the auditing log is automatically closed and a new log is opened in its place. This upper limit is set (and read) via the auditconfig(1M) command:

SYNOPSIS

auditconfig option...

[...]

-setfsize size

Set the maximum size of an audit file to size bytes. When the size limit is reached, the audit file is closed and another is started. If perzone is not set, this option is valid only in the global zone.

While still documented, this functionality, however, does not work correctly in Solaris 10 and beyond.

In Solaris 9, the actual writing of all of the auditing data to disk was handled by the kernel, with the job of the userland auditd(1M) deamon being only to perform the initial setup of the auditing log and then hand everything over to the kernel (basically by calling auditsvc(2)) and then waiting until the kernel reported that something had gone wrong. As a result of this, the implementation of the upper limit for the auditing log (in other words, the code that stopped writing data once a certain amount of it had been written) was implemented in the kernel, and the interface for making use of it was provided via a system call (and the auditconfig command mentioned above makes use of the system call).

In Solaris 10 things changed significantly. A new project was initiated to alter the auditing subsystem so that instead of just writing auditing data to a binary file on disk, a plugin architecture was produced which would allow new output methods for the logging of the auditing data to be created, and then for these to be freely configured for use on site (and even allows different plugins to act on the same auditing data together). It makes sense for these plugins to run in userland (rather than requiring them to be kernel modules or something similar, as this would limit the usefulness of the plugins and put an extra burden on the people creating them). So the auditing subsystem was split into two across the kernel to userland boundary. Rather than just dispatching the writing of the auditing data to the kernel and then going away, as occurred previously, the auditd daemon now registers a door server with the kernel and stays awake. As the kernel generates auditing data it passes the data back down into userland to the running auditd daemon via the door server, where auditd then takes over the responsibility of recording the auditing data by passing it to the available plugins which in turn handle actually recording the data using whatever method they are intended to implement.

The default plugin, audit_binfile(5) just recreates the previous behaviour of writing the log to a binary file. As a further example, the new plugin audit_syslog(5), writes the data to the system log instead (where you can configure it via the usual syslog.conf(4) method).

All of this means, however, that the kernel code which previously handled the auditing file size limit, was no longer applicable, because the auditing data was no longer written within the kernel. Furthermore, the whole concept of a file size limit is specific to the process of writing data to disk, and therefore doesn't match the new generic paradigm where the auditing subystem no longer knows what happens to the auditing data once it is passed to the plugins. As a result, setting the kernel-based file size limit using the traditional '-setfsize' auditconfig command had no affect, and no alternative userland implementation had been created to replace it.

I have recently been working on a project to rectify that last problem, and the fruits of that project were integrated into OpenSolaris build 91 (see here for diffs). As the actual writing of the auditing data to disk now occurs within the audit_binfile(5) plugin, this change creates a new parameter associated with that plugin, called p_fsize, which when set will produce the same functionality as was previously available via the '-setfsize' command, namely it will close the audit log when a certain limit is reached and open a new one. This parameter can be set within the audit_control(4) file in the normal way, for example:

plugin: name=audit_binfile.so.1;p_fsize=512000

which will set the filesize limit to 512,000 bytes. Here's a quote from the updated OpenSolaris audit_binfile(5) man page which describes this feature:

The p_fsize attribute defines the maximum size in bytes that an audit file can become before it is automatically closed and a new audit file opened. This is equivalent to an administrator issuing an audit -n command when the audit file contains the specified number of bytes. The default size is zero (0), which allows the file to grow without bound. The value specified must be within the range of [512,000, 2,147,483,647].

Update: This fix is now available in Solaris 10 as of 10/08, and is documented in the corresponding man pages. It is also available in patches 138085-01 (SPARC) and 138086-01 (x86).

Thursday May 10, 2007

Time - our most valuable commodity

Thanks to hint from an article I read in the paper the other day, I grabbed a copy of Arnold Bennett's How to Live on 24 Hours a Day, and it's a fine read indeed. Its tempting to bill this concise instructional guide as an Edwardian Getting Things Done as it definitely seems to share some of the same ideals and appeal. For me though, what is most enchanting about this book is its charming and avuncular writing style that makes you feel like you are getting a caring but cheeky telling off from an old friend. With such quaint delights as Bennett's response to the man who just can't get up early because he needs his servants to make him tea in the morning (have your servant leave a spirit lamp with a pot of tea on it outside your room before bed, of course!) you can't help but read this book with a great big smile on your face all the way through. But inescapably, this book leaves you genuinely inspired. It so compellingly reminds us that time is indeed life's greatest commodity, and that you can never get in debt with time because no matter how you spend today, tomorrow will always be there waiting for you in all its glory. Bennett encourages us to wrestle life back from the clutches of procrastination and apathy by developing our ability to pay attention to what is going on around us and to get maximum value from every moment, cheifly by educating ourselves (and not falling into the trap of thinking we have low energy; tiredness is voluntary!) and by exercising our minds. Well worth a read.

Wednesday February 28, 2007

in.telnetd exploit propating

It looks like a worm which takes advantage of the in.telnetd vulnerability that we described in Sun Alert 102802 a little while back is now being propagated around at least some networks.

The security team has posted some further details on our blog describing how to determine if a machine is infected, along with a script that removes the footprint (as far as we are aware of it). It also disables telnet in the process, which is something that should probably be done on all Solaris 10 or Nevada hosts right now anyway (even without this new development), at least until the machine can be patched as described in the resolution section of Sun Alert 102802.

Thursday February 15, 2007

in.telnetd vulnerability: fun with zero-days

Its been an interesting few days in the vulnerability team at Sun. As most readers of this entry will likely be aware, a serious vulnerability in the in.telnetd daemon shipped with Solaris was announced publicly on Sunday, which led to a great flurry of activity to get the issue resolved.

Thanks to work of a number of dedicated engineers who were on the ball on Sunday, and who ran with this, within a few hours of it being reported, Sun had a fix reviewed and integrated into Nevada (the current Solaris development release). Alan Hargreaves then jumped on this and started the backport to Solaris 10 (older releases are unaffected), and he has given a detailed summary of his experiences on his blog (well worth a read).

When I got into work on Monday morning Alan already had IDRs (a form of interim fix packaged up into a patch) available internally and a Sun Alert draft was in progress. In addition he was getting ready to submit his RTI (request to integrate) for the patch gates, he just needed a code reviewer and our team was happy to oblige.

The next step was getting Sun's official response published, in the form of a Sun Alert and the IDRs containing the fix. It was an advantage in this case that the problem was relatively easy to understand for someone familiar with Solaris, and as a code reviewer of the backported fix, putting together the technical details of the Sun Alert was relatively straightforward. We double checked that the IDRs worked and then passed them along with the Sun Alert to the next stage of the process, waiting for them to be published.

By Tuesday evening we had official patches tested and published.

Obviously when going through any experience like this, where our team is tested and where it's working on precisely the kind of problem for which it was invented, we learn lots of things. One of the most important, and perhaps surprising, things for me was the attention that the team's blog received.

We're still finding our feet in terms of the value that the blog can add, and it is currently effectively just a mirror of the security Sun Alerts published to Sun Solve. However, what surprised me was that for many people this is the first place they look to learn about security vulnerabilities in Sun's products. Unfortunately due to a bug in the tool the notification about the telnetd Sun Alert did not hit the blog until a good few hours after it was published on Sun Solve, and this upset a few people. We have now learned that this resource is important to people and we are hoping to raise its priority within the team.

But there's a deeper lesson to learn than that. It seems that people were following the blog because they wanted up-to-the-minute information about the progress of the vulnerability and its resolution. They wanted to actually follow the story. And not just the facts of the case, but the feedback that I have seen about Alan's blog entry has shown that people are interested in the personal voice as well. Understandably SunSolve, which is a very professional site supported by a huge infrastructure, is not designed for that sort of thing. Sun as a whole has already learned this lesson with the introduction of blogs.sun.com, and now it looks like this message is starting to filter down to the security team too.

So in hindsight it seems that our team could start filling in the blanks between the movements of the big SunSolve machine with less formal communications via outlets such as our blog and the many OpenSolaris discussion lists. An example of the kinds of things we're thinking about are potentially putting up a draft of the Sun Alert onto the blog as soon as we have finished writing it, which in this case would have meant it was available a good few hours before it appeared on Sun Solve. Another request we're exploring is allowing comments on the security blog, so that it will be more of a conversation than an information drop.

This is a learning process, and we've got a long way to go. Perhaps the readers out there can help us along the way!

Tuesday February 06, 2007

Forcing people to register email addresses

I heard a report on the news this morning related to proposed UK legislation which could force sex offenders to register their online identity ("e-mail addresses and chatroom names" are mentioned in the article) to allow for an early warning system when those identities were used in an inappropriate forum.

Now, I'm all for the concept of helping people to identify dangerous members of society (once convicted as such) prior to that danger manifesting itself, but I am left wondering how practical this proposed solution really is. As far as I know, it is trivially easy to create new email addresses by registering with one of the many email providers out there, so there is no way of preventing the offenders in question from having multiple online identities which cannot be easily traced back to the owner (presumably if they could be easily traced, this legislation wouldn't be required in the first place) and then only registering a subset of those identities. So how would this system actually work?

Monday February 05, 2007

File descriptors and setuid applications

A recent (-ish) post on BugTraq by the XFOCUS team spawned some discussion internally. Prior to publication of this issue, XFOCUS contacted us folks in the security vulnerability team for a response, which we provided.

It seems to us that this report is highlighting a general warning about a programming error which can lead to security vulnerabilities. When a Solaris process (and those within other Unix's) launches another application (e.g. via exec(2) or one of its relations) the new process image inherits the previous image's open file descriptors. In Solaris, this fact does not change when a setuid application is launched. Because a user has control of the process from which he or she launches setuid applications, that user can therefore control the file descriptors that are inherited by the setuid application. As a result, this puts a burden on the setuid program, demanding that it use its inherited file descriptors in a safe fashion so as not to allow this situation to be exploited (and this issue is mentioned in a set of secure programming guidelines distributed within Sun that is hopefully read by engineers who are creating or fixing setuid binaries).

The exploit contained within the SecurityFocus post takes the form of a setuid binary which is a manufactured example of this kind of programming error. It writes directly to file descriptor 2, assuming that it's the usual stderr, but of course this assumption is not safe, and because the calling process closes file descriptor 2 before exec-ing the setuid program, the open(2) that occurs earlier within the setuid binary will result in that file being opened as file descriptor 2, causing the setuid application to write to that file incorrectly, at the behest of the user controlled exec-ing process.

Hopefully these programming errors are not prevalent in Sun's code (but of course if there were no vulnerabilities we wouldn't need a vulnerability team), and searching for these kinds of errors is part of the general code sweeping and review processes that go on at Sun. Certainly if a specific instance of this problem is found in an app shipped by Sun, then that is an issue that Sun would work on fixing (by patching the setuid application) and publishing in the form of a Sun Alert as soon as possible (and our team always welcomes disclosure of such issues via our normal mail address), but the security vulnerability team does not currently have plans for a direct response to the general warning published by XFOCUS.

Wednesday December 13, 2006

USB storage on the SunRay

My SunRay experience just gets better and better. This morning I decided to try plugging a USB pendrive into the SunRay1 on my desk, and to my utter amazement and jubilation, I had it mounted and working within about 10 seconds. So now, not only can I pick up my session and continue working in our office that's 20 miles up the road, but I have an easy to use, permanent storage that I can access on pretty much any machine that I'm likely to use (until I lose it of course...). This rocks.

The full details are available in the official docs, but for a quick summary: first you need to be using at least SunRay Server Software 3 (where support for these devices was introduced), and then, assuming the server is configured properly, you can just plug your USB storage into the SunRay and it will be magically mounted under /tmp/SUNWut/mnt/<userid>/, which a quick call to /opt/SUNWut/bin/utdiskadm -l should confirm. To unmount, just call /opt/SUNWut/bin/utdiskadm -r <device>.

Tuesday January 03, 2006

Weightwatching: Future Thin Clients?

Chandan, a fellow member of the security co-ordination team and Sun-blogger, recently posted some very interesting thoughts on a possible future thin-client (which were also reported by Engadget recently). This delightful (and so far fictional) device, shown in the blog entry with convincing mock-up photos, combines the Sun Ray technology and the smart card that enables it to create the thinnest of thin clients. The card itself is imagined with an E-Ink screen which displays a workspace sent to it directly via a server. As a result, and like the existing Sun Ray technology, all of the processor power and storage belongs to the server, making the All In One Card (as Chandan nicknamed his creation) a flexible low-power high-storage location-independent device. When at home base the card could be plugged into a larger device, presumably connected to a traditional display and keyboard, transferring the session to the larger screen.

As Chandan notes in a follow-on entry to the original post, the developers of the Sun Ray technology have been focussing on greatly reducing the bandwidth that it requires, to the point that it is now possible to comfortably use a Sun Ray over a traditional home broadband connection. With these low bandwidth requirements, the AIO card could be used anywhere that a reasonable wireless Internet connection is available. In the current climate though, that would seem to be the main stumbling block as the wireless culture just isn't mature enough yet such that this device would be useful in the majority locations. However, ubiquitous Internet connectivity is a goal that is looking more and more achievable everyday.

Monday January 02, 2006

Pitch Drop Experiment

Thomas Parnell's Pitch Drop Experiment is a fascinating illustration of the unobservable attributes of everyday objects (admittedly pitch may no longer fit that description). It provides a thought provoking example of something that requires not the global form of co-operation that the Internet can bring, but instead a cross generational co-operation. It illustrates something that is not perceptible by individuals in a short space of time, but instead by investing in the future Parnell gives us a history that we can retrospectively interpret and learn from. As well as a fascinating experiment, it makes for a great example of the kind of debts that we owe to previous generations. ( Jan 02 2006, 03:06:40 PM GMT ) Permalink

Thursday December 22, 2005

London OpenSolaris User Meeting Report

On Monday (19th December) I attended the latest meeting of the London OpenSolaris User Group. This was a very interesting event. It was difficult for me to judge the ratio between Sun and non-Sun attendees (the majority of faces were unfamiliar to me) but I would like to think that it was a popular event beyond the Sun staff.

The event was opened by a detailed talk about DTrace from Jon Haslam. This talk turned out to be a highlight of the evening, as rather than being just another demo of the technology, it was instead an examination of the design and implementation of DTrace. This included an analysis of how your D code is converted into the DTrace virtual machine opcodes and how these objects are then injected into the kernel so that they are executed when a newly activated probe is 'hit'. In all it made for a very helpful precursor to delving into the sourcecode.

We were also joined by a welcome guest from overseas, Adam Leventhal. He is a member of the Sun engineer elite, probably most famous for his his membership in the DTrace team. In the latter capacity he contributed to the meeting by assisting Jon in his description of DTrace. However, he also presented us with a new project, BrandZ, which I had heard of in the past, but haven't had an update on in a while.

This is an interesting project which aims to allow binaries from non-native OSs (e.g. Linux) to run unmodified in a Solaris zone (on a matching processor architecture) by 'booting' a Branded (non-Solaris) Zone and emulating the guest OS' kernel API there (for the most part this means the kernel's system calls). Unfortunately the talk was only a quick (5-minute) demo and proof of concept, but it was very interesting to see that real progress is being made on this project, which is now available for download via OpenSolaris.

This was then followed by a general overview of ZFS, and why its great, as presented by fellow GMP-er, Tim Graves. This presentation is great, and I have seen it presented while I was in the states by the ZFS team themselves, but unfortunately due to a lack of time Tim had to run through it a bit quicker than it deserved. However, ZFS remains a fantastic technology which I love to play with. Its unfortunate that as a technology it can sometimes be a bit of an underwhelming demo because it is designed to make things easy, and things always seem easy in a well prepared demo. The only real way to get a feel for how revolutionary ZFS is is to download it and give it a go, something which I highly recommend doing.

Next up was another quick presentation about a new Solaris related technology, this time the port of Solaris to Xen (a free open source virtual machine type program, allowing you to run multiple OSs at once). The good news is that this project is making progress and has a currently working demoable status.

Next we had a talk on an important topic which is currently starting to get the attention it deserves in Sun: performance. Phil Harman, who presented this talk, is one of the leaders of the movement to put performance on the top of the agenda within Sun (he coined the oft-quoted phrase 'If its faster in Linux, its a Solaris bug'). One of the interesting things that he discussed was the work his team was engaged in in changing the default attitude of Sun, and the best way to convince engineers of something is to prove it in practice, so the team developed a portable benchmarking tool libmicro to produce real provable statistics. This tool is designed to make it easy to create benchmarks that test your favourite portable APIs on different platforms and it has been successfully run on most obvious modern Unixes (Solaris, Linux, Windows Services for Unix, MacOSX etc). This application is now available online and Phil encouraged everyone to download it and create thier own benchmarks to see how Solaris compares in thier favourite APIs. And if Solaris doesn't compare favourably, we want to know about it!

Finally, Darren Moffet closed the show with a quick presentation of Sun's efforts to integrate encryption into our filesystems. He gave a summary of the field and Sun's design decisions in implementing this forthcoming project.

All in all it made for a very interesting evening.

( Dec 22 2005, 04:59:12 PM GMT ) Permalink

Tuesday June 14, 2005

A Simple Userland Bugfix

Now that OpenSolaris is up and running, we can talk more freely about the source code that we work on everyday. I thought I'd celebrate this launch by narrating the investigation of a simple userland bug fix that I worked on recently. Although there's nothing magical or ground-breaking here, it might still provide some insights into the bug-fixing process for those who aren't familiar with it, and to at least one small part of the Solaris code for those who are.

The bug was discovered in the Solaris implementation of one of the ancient and ever-ready Unix tools: xargs(1). The job of this tool is to collect arguments via the standard input and to bundle them up into argument lists to be passed to another tool. Its one of those commands that you probably think you'll never need, but every now and then you come across some situation where it does exactly what you want (and nothing else!). So many Unix tools fit that description!

For the most part, this tool works great, however, one user discovered that when given a specific kind of input, it wasn't behaving as expected. In the test case provided, the input to the command is quoted with a backslash character, meaning the spaces should be ignored (causing each line to be treated as a single argument). This input is passed to a command which prints each of its arguments on a line by itself. In this scenario, because each line is a single argument and each argument is printed on a single line, the input should be the same as the output. However, when given a sufficiently large input text, the output would slightly differ: new lines were added in certain places. Bug 6203159 was duely logged, and I was tasked with fixing it.

After getting a reproducible test case up and running, we can start digging a little further into exactly what is happening when the error occurs. We can recreate the problem with a simplified test case, using the -s flag to the xargs command to artificially limit the maximum length of the command line argument that xargs builds up (perhaps a clue about where the problem might lie...):

$ xargs printf "%s\n" <<EOF
> one\ line
> one\ line
> EOF
one line
one line
$ xargs -s 26 printf "%s\n" <<EOF
> one\ line
> one\ line
> EOF
one line
one
line

The output of these two invocations should be the same, however we can see that in the second case limiting the length of the created command line corrupts the output. Lets use truss(1) to find out exactly what commands xargs is executing (-t lets us just trace the exec(2) system call, -f says to also trace child processes, and -a prints out the arguments passed to exec-like system calls):

$ truss -fat exec -o truss.log xargs <testdata -s 26 printf "%s\n" >/dev/null
$ grep -v ENOENT truss.log                                         
14433:  execve("/usr/bin/xargs", 0xFFBFF3E4, 0xFFBFF3FC)  argc = 5
14433:   argv: xargs -s 26 printf %s\n
14437:  execve("/bin/printf", 0x00024B7C, 0xFFBFF3FC)  argc = 3
14437:   argv: printf %s\n one line
14442:  execve("/bin/printf", 0x00024B7C, 0xFFBFF3FC)  argc = 4
14442:   argv: printf %s\n one line

Now, this is very interesting, because we can see that in the second invocation of printf(1) we are passing 4 arguments instead of three (the 'argc = 4' text shows this) so the words 'one' and 'line' must be being sent in the second case as separate arguments: the '\' isn't doing its job. So some where in the part of the code where xargs builds up its list of arguments, we're losing this special character.

With a good idea of where the problem is occuring, we can turn to the code. xargs builds up its argument list character by character within the getarg() function. The main loop here starts at the follwing lines:

	for (arg = next; ; c = getwchr()) {
 		bytes = wctomb(mbc, c);
        ...

so lets grab our trusty debugger (in this case dbx), get the thing running within it, and stop execution at the second line above. We can then watch the argument build up for a while:

(dbx) runargs <testdata -s 28 printf "%s"                                    
(dbx) stop at 548                        
(2) stop at "xargs.c":548
(dbx) run       
Running: xargs -s 26 printf %s < testdata 
(process id 2244)
stopped in getarg at line 548 in file "xargs.c"
  548                   bytes = wctomb(mbc, c);
(dbx) display arg
arg = 0x268a2 ""
(dbx) cont      
stopped in getarg at line 548 in file "xargs.c"
  548                   bytes = wctomb(mbc, c);
arg = 0x268a2 "o"
(dbx) cont
stopped in getarg at line 548 in file "xargs.c"
  548                   bytes = wctomb(mbc, c);
arg = 0x268a2 "on"
(dbx) cont
stopped in getarg at line 548 in file "xargs.c"
  548                   bytes = wctomb(mbc, c);
arg = 0x268a2 "one"

So we can see the string being built up bit by bit. Lets skip on to the second line just before our magic '\' is read in:

(dbx) cont
stopped in getarg at line 548 in file "xargs.c"
  548                   bytes = wctomb(mbc, c);
arg = 0x268ab "one"
(dbx) next
stopped in getarg at line 551 in file "xargs.c"
  551                   if ((next + ((bytes == -1) ? 1 : bytes)) >= &argbuf[BUFLIM]) {
arg = 0x268ab "one"
(dbx) print c
c = '\\'

So we can see from the output of 'print c' that our current character is indeed our slash. What happens to it? Well a switch statement is run on the character and eventually it is discovered to be a quote char:

                  case L'\\':
                         c = getwchr();

at this point, our 'c' is actually thrown away and the character following it is read in instead. This is how the quoting is implemented because this happens after a character's special meaning is determined, meaning the space character (in this case) gets copied directly to the argument, and the '\' is removed:

(dbx) cont
stopped in getarg at line 548 in file "xargs.c"
  548                   bytes = wctomb(mbc, c);
arg = 0x268ab "one "

So far so good. But where does it all go wrong? Lets follow the execution a bit further. At some point, we reach the limit of our buffer (which, if you remember, we have artificially shortened with the '-s' switch) and when that happens, we enter the code within the following if statement:

if ((next + ((bytes == -1) ? 1 : bytes)) >= &argbuf[BUFLIM]) {
...

At that point, we have a nice comment that describes what happens next:

/*
 * Otherwise we put back the current argument
 * and use what we have collected so far...
 */

So wait a minute, alarm bells are ringing now: when we can no longer read any more input we requeue what we have read in so far so that it can be re-read in the next iteration:

...
(void) strcpy(so_far, arg);
...
queue(so_far, len, HEAD);

Hang on a minute, haven't we removed the '\' from the argument that we have built up? Yes, that means when we perform this requeing, we lose the quote character and just requeue a lonely space, meaning when that text is re-read the space will be active, causing the symptoms we've seen here.

So that's it, after a lot of digging we have worked out what is causing the problem. As for how it was fixed, well that's another story. Why not dig through the OpenSolaris code and answer that question for yourself?

Technorati Tag: OpenSolaris Technorati Tag: Solaris ( Jun 14 2005, 06:02:52 PM BST ) Permalink Comments [0]

Monday June 13, 2005

Let the SunRay shine

This isn't just corporate but-kissing: I really love the SunRay technology. For those who don't know, the SunRay is a very thin client which effectively works as a remote display for a session running on a high-powered shared server. I use one everyday at work and I love being able to pull my smartcard out of the device and travel to a different building (even a different town), plugin the card and have my session appear immediately on the screen as if I'd never left it. This ability particularly comes into its own for me because I split my working week between two different offices in different towns. Regardless of where I am I get the exact same work environment and can seemlessly shift from one office to the other and pick up exactly where I left off.

This technology would be so useful in any environment where large numbers of computers are shared. Besides the advantages offered to the system administrators (SunRay's themselves don't require maintenence: if they go wrong you just replace them entirely, which is easy to do as they are stateless) they are extremely convenient for the users. So many times when I was at university, making use of the shared lab there, did I wish we were all kitted out with SunRays instead of the standalone PCs, because often we would have to move from one area of the lab to another chasing the free machines as those we were on got booked up during the day. Its also a great way for people to feel some kind of ownership over thier use of shared computing resources, because you now that your session is yours, and it follows you wherever you go. Great stuff.

Tentative beginnings

Like many of my colleagues here at Sun I have finally committed to finding my voice and beginning a blog here on blogs.sun.com. I have been blogging externally for some time now (in fact, since before I joined Sun) and I intend to continue to maintain that blog with more personal items (for example, much of it is in Esperanto; I will try and stick to a single language in this blog!). This area, while no doubt still containing the odd personal observation, will be more closely linked to whatever work I happen to be doing here at Sun.

So far I have a relatively short but exciting history in the company. I joined Sun for the first time in 2001 as an intern, where I worked as a lab engineer in the PTS lab team (frequenters to this site my recognise that Paul Humphreys manages and frequently blogs about this team and their work: while I was student he was my manager).

After returning to university and completing my degree I returned to Sun just over a year ago (March 2004) to work in the revenue product engineering group. Our core responsibiliy in this team is to fix customer escalated bugs in Sun's products. In addition, we have many other contributions to Sun's software group, which you can no doubt read more about here in the coming months and in the many other RPE blogs out there.

I am currently in the utilities group (which deals with many userland Sun products) specialising in the N1 product range, and it is in this space that most of my work has been done to date. This includes working on Sun's contribution to the service provisioning market, N1 Service Provisioning System, as well as a few other datacenter focused products.

I will soon be transitioning to the security coordination team, so I anticipate that in the future this blog will gradually adopt a more security-related focus as I find my feet and become more at home in that area.