James Morris

Labeled NFS Requirements Draft Submitted

2008-05-02T00:54:55Z

Dave Quigley has just submitted an Internet Draft to the IETF outlining the requirements for Labeled NFS:

MAC Security Label Requirements for NFSv4 (link)

Abstract This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.1 . It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer and why existing NFSv4 protection mechanisms are not sufficient.

This draft is a generalization the original Security Enhanced NFS document posted last year, addressing the general need for mandatory access control support in NFS.

NFSv4 currently supports two access control schemes: standard DAC and ACLs. MAC labeling support is required for technologies such as SELinux and OpenSolaris FMAC.

Essentially what's needed is a way to convey MAC labels over the wire (for both setting and retrieving their values), and to be able to enforce security policy using those labels. The server needs to be able to determine the security label of the remote client process when enforcing policy, and all systems need to be able to ensure they understand each other's labels, or be able to translate them. A "Domain of Interpretation" (DOI) attribute is used to determine the meaning of labels, a term which may be familiar to those who've braved the IPsec specifications. The confidentiality and integrity of these security attributes must be protected in transit, while all parties need to be authenticated. We also need to be able to handle the case where either the client or server does not have MAC enabled, and to ensure non-breakage with existing implementations. There's a lot more in the details, but that's the gist of it.

It may seem at first glance that NFSv4 named attributes (NAs) would provide the required labeling functionality, but they're not a good fit. NAs are specifed as opaque to the system and user-managed, while MAC security labels are managed by the system. NAs also do not provide necessary semantics such as conveying client security attributes or negotiation of DOI. There are also issues with attribute namespaces (which are user-managed and unspecified) and labeling atomicity. Another possible approach is to implement Linux/BSD-style extended attributes (EAs), which are simple text string attributes associated with files, in contrast with the NA "subfile" scheme. This would potentially only solve the attribute namespace issue, and is also not a good general solution. EAs are also not currently part of the NFSv4 specification, and it seems like a contentious area in any case.

The current Labeled NFS prototype code utilizes NFSv4 recommended attributes (RAs), which are fully extensible, already exist, and are already used for similar management of metadata (e.g. ACLs). This seems to be the simplest and most straightforward approach.

Once there's consensus on the requirements, the next step will be to develop a protocol specification and hopefully have it incorporated into NFSv4. v4.1 is currently in "last call", so the next candidate would be v4.2, it seems. The prototype code for Linux/SELinux will continue to be developed alongside the standards process.

For those interested in following or contributing to the project, there are several relevant mailing lists:

Dave is hoping to have further discussion IETF 72 in July, and will be presenting on the state of the project at the SELinux Developer Summit ahead of that.

2008 SELinux Developer Summit Schedule Now Up

2008-04-29T01:26:17Z

We managed to get the SELinux developer summit schedule published a few days early. Hopefully, this will help people who are making travel arrangements to OLS.

As mentioned, a lot of high quality proposals were submitted. To ensure that all important topics can be covered, the format of the summit has been changed to moderated discussion panels with presentations; rather than the original plan of having a set of fixed-length presentations followed by discussion panels.

Presentations will now be 10-20 minutes, with a greater focus on discussion. This provides much more flexibility, and is derived somewhat from experience with the kernel networking summit, which has been very successful with short presentations driving discussions.

The panel sessions are as follows:

Community
Applications
Desktop
Distributed Technologies
Policy Configuration
Policy Infrastructure
Emerging Technology/Works in Progress

More detailed information, including topics, issues, and links to abstracts may be found at the schedule page. Also see the printable version and the topics page.

All SELinux developers and folk with a technical interest in SELinux and related technologies are welcome to attend. Don't forget that you also need to be registered to attend OLS.

SELinux documentation in Portuguese / Monografia sobre SELinux

2008-04-28T01:08:15Z

Jeronimo Zucco has published some SELinux documentation in Portuguese:
Hardening Linux Usando Controle de Acesso Mandatório.

Relatedly, I just read Spot's report on attending FISL in Brazil. Sounds like it was an exciting and productive event. With over 7000 attendees, I wonder if this was the largest FOSS conference ever?

SELinux Developer Summit: CFP closed

2008-04-21T11:22:06Z

The 2008 SELinux Developer Summit CFP is now closed.

As suspected, most of the proposals arrived at the last possible moment. It looks like we have more proposals than can reasonably fit in one day, so the organizing team now has the interesting task of squeezing as much in as possible without overloading the schedule. This is going to be very difficult, as pretty much all of the submissions are of excellent quality.

In any case, we should have the schedule finalized and published within a week or so.

SELinux Developer Summit 2008 - CFP ends this week!

2008-04-14T23:57:19Z

The Call for Participation for the 2008 SELinux Developer Summit closes on the 18th of April -- that's this Friday!

If you've been working on something interesting, there are some slots still open for the informal 30-minute talks. We're also accepting suggestions for discussion topics and panels.

Send your ideas/proposals to the organizing team: selinux-summit-team AT namei.org

SELinux Developer Summit 2008 Announced

2008-04-02T00:40:49Z

We've just announced the SELinux Developer Summit for 2008, which will be held in Ottawa (as an OLS mini-summit) on July 22nd. A CfP will be issued early next week, where we'll be looking for people to submit talks and panel topics.

In previous years, the project has had the SELinux Symposium, generously run by Tresys, with an invite-only developer summit tacked onto the end.

The new Developer Summit is intended to track with the evolution of SELinux as a wider community project, and we are very pleased to be able to hold an open event this year in conjunction with OLS.

All developers and folk with a strong technical interest in SELinux and related Flask/TE projects are encouraged to attend. Note that attendees need to also be registered for OLS.

There'll be more information on the CfP and schedule soon -- this is something of a heads up for those planning travel and who may be wish to start thinking about presentation and discussion topics.

The organizing team is as follows:

Serge Hallyn (IBM)
Paul Moore (HP)
James Morris (Red Hat)
Chad Sellers (Tresys)
Stephen Smalley (NSA)

For more details on the event, including contact details for the team refer to the SELinux Developer Summit page.

So, there'll be quite a lot of SELinux content at OLS, some of which I've previously mentioned. To summarize, in addition to the Developer Summit, there'll be:

Talks:

SELinux for Consumer Electric Devices by Yuichi Nakamura of Hitachi Software.

Have you driven an SELinux lately?, an update on the state of the SELinux project by... me :-)

A tutorial:

Confining the User with SELinux by Dan Walsh, star blogger.

A BoF session:

NSA Security-Enhanced Linux Users chaired by Dave Quigley of Labeled NFS fame.

So, if you're involved with SELinux or otherwise interested in it, I'd suggest flying, driving, walking or swimming (I'm pretty sure this is possible) to Ottawa this July.

I forgot how much fun it is to write a paper

2008-03-27T03:55:02Z

Because the cool kids are doing it, here are photos of the bookshelves above my desk:

Click for more detail.

It's really great being able to reach over and grab whatever I need without going anywhere. Some would call it lazy; I'd call it efficient.

OLS 2008 schedule up

2008-03-20T15:26:29Z

The OLS 2008 schedule is up:

There are quite a lot of security-related items this year, with several covering SELinux. I've had a talk accepted on the general state of the SELinux project. If you can read Japanese, see Yuichi Nakamura's blog entry (he's presenting on SELinux in consumer electronics).

We're hoping to hold an SELinux developer event in conjunction with OLS. Hopefully there'll be more to say on that soon.

It's interesting to see so many Indian flags next to speakers' names this year. No doubt related to the enthusiastic efforts of the grassroots community in India as evidenced by FOSS.IN and the growing number and scope of regional conferences.

A quick google returns regional conferences this year in Delhi, Calicut, Chennai and Pune. I probably missed some. A few of them happen around the same time (February or so ) and if its similar next year, then there's scope for folk who are interested in both traveling around India and in FOSS to do some kind of geek tour -- on PTO, I'd imagine, unless your management is epically cool.

SELinux support in Ubuntu 8.04 ("Hardy Heron")

2008-03-19T02:15:54Z

Christer Edwards has announced support for SELinux in Ubuntu 8.04, and documented the installation procedure:

  $ sudo aptitude install selinux

It's great to see other distributions adopting SELinux. I'm anticipating that the Ubuntu community will bring in fresh ideas and perspectives based on their overall focus on usability.

SELinux has always been an entirely open project and it was never intended to be specific to any particular distribution or company (a perception which unfortunately has emerged in recent times). Hopefully, adoption by Ubuntu (and others) will help to dispel such myths, including the myth that SELinux is difficult to use. It would be unrealistic not to expect a few teething problems in Ubuntu, but experience with Fedora has shown that they can be fixed, and that stronger security can be made highly usable in the general case.

Something interesting to consider is that with SELinux support, Ubuntu is now a potentially LSPP/EAL4+ certifiable distribution. As many will know, such certifications are important requirements for significant classes of government and military procurement, and we are also seeing some such users moving exclusively to open systems.

Side note: it seems that there'll be some SELinux talks and events at OLS: nothing official quite yet, but keep your calendars open!

SELinux Odds and ends

2008-03-11T14:45:35Z

What is Security Enhanced PostgreSQL ? Good overview from Kaigai Kohei, with cute diagrams.

Schneier blogs about the future of security as a standard feature, eliminating the "best of breed vs suites" decision:
That they're forced to spend money on IT security is an artifact of the youth of the computer industry. And sooner or later the need to buy security will disappear.

It will disappear because IT vendors are starting to realize they have to provide security as part of whatever they're selling.

Interesting article, but the concept of shipping security features by default is significantly established and even pioneered within FOSS. For example, the idea that mandatory access control could be enabled by default, in a general purpose OS, was I think unheard of until SELinux was released as a standard part of Fedora.

Linux systems have many best of breed security features available as standard, typically for free: firewalling, PAM, OpenSSH (thanks OpenBSD folk), binary protection, code review, vulnerability response, audit, crypto, network stack hardening, and so on. The inclusion of such features as standard, rather than expensive, layered products with vendor lock-in written all over them, is itself an innovation in computer security. An innovation which is being adopted by major OS vendors.

I was surprised to see Bruce interviewed a few months back, being asked what he thought Linux had contributed to security, and to see him answer something along the lines of merely raising the bar for Windows. That may be true to an extent, but I think he seems to underestimate (or not understand) the direct value provided now to the millions of systems running Linux, many of which are running all kinds of critical workloads. We're talking stock exchanges, large banking systems, Google, telephone exchanges, cell phones, supercomputers, file and print servers, much of the web, mail servers, routers, hospitals, military, government, and almost anything you can think of. FOSS achievements stand alone, and frankly, have enabled progress which simply would otherwise not have occurred.

For those who may have missed it, Linuxworld covered SELinux mitigation of vulnerabilities. I was interviewed for this, which I think is the first time I've been interviewed for a magazine.

Government Computer News has coverage of the Labeled NFS effort on its front page today. Dave Quigley presented on the topic this week at IETF 71 -- it'll be very interesting to see how that turned out, as IETF acceptance is a critical requirement for the project.

OpenSolaris to adopt Flask/TE security scheme

2008-03-04T22:25:41Z

As noted at SELinux News, OpenSolaris has launched a new project, Flexible Mandatory Access Control (FMAC), to integrate the Flask/TE security scheme into their OS. This is the same underlying model implemented by SELinux, and follows other cross-platform Flask/TE integration projects such as SEDarwin and SEBSD.

This is very exciting in terms of of establishing compatible security across operating systems, particularly for Mandatory Access Control, which has traditionally been narrowly focused and generally incompatible. With FMAC, we're closer to seeing truly ubiquitous, cross-platform MAC security.

I'll be interested to see how they approach the integration, with the opportunity to learn lessons from the SELinux experience.

It'll also be great to have an expanded TE/Flask community. According to their project page, areas of work include improving usability (we can never have enough of that), desktop integration via XACE, integration with Xen (presumably via XSM), Labeled NFS, and Labeled IPSec. It seems they already have a separate project for the latter, txipsec.

I'll be watching with great interest, and would like to offer any assistance in ensuring interoperability with SELinux.

$100k FIPS-140 certification vs. $19.95 Amazon purchase of Scrubs DVD

2008-02-25T23:25:34Z

My morning email slog was greatly enhanced by some choice quotes from Peter Gutmann on the IETF Security Area Advisory Group list:

Compare this to the example I gave earlier of performing a TLS exchange with Amazon. This performs an in-depth test of all the crypto algorithms (corresponding to the FIPS algorithm tests, including ones that FIPS ignores), and the crypto mechanisms (many/most of which FIPS again ignores). In other words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for $19.95 I'm getting more comprehensive algorithm testing than I can for a five-figure sum with the FIPS algorithm tests.

This was based on a FIPS-140 crypto certification costing $100,000 (which was challenged in a followup as costing a mere $30,000).

He then describes what he believes would be a better way to use the $100k in assuring a crypto product, including the purchase of a $45k home theater system, beer, and setting a up fake banking web site as a honeypot to attract Russian mafia.

The Linux Foundation does not speak for me

2008-02-21T22:57:48Z

I'd like to say, somewhat for the sake of the OpenSolaris folk who are currently having a bit of a rough time, that I personally strongly disagree with certain statements coming out of the Linux Foundation, such as those claiming that the "L in LAMP is literal". ^[1]

Of course, LAMP has long been representative of the concept of a free software stack. The term itself has been tremendously useful as a means to identify an open approach to developing and deploying systems. The L does of course not have to mean Linux any more than the P needs to mean PHP or Perl. Aside from OpenSolaris, there are many good choices for operating systems in an open stack, such as OpenBSD.

While LF is an industry consortium representing several companies and organizations with various interests in Linux, it certainly does not generally represent the Linux community.

As a Linux developer, I'd like to continue to extend support and encouragement to OpenSolaris developers.

I believe that such attacks on other open projects serve to damage the general interests of FOSS. Interestingly, LF has granted itself authority to respond to "competitors’ attacks" ^[2], a role which is surely undermined by themselves undertaking such attacks, especially on emerging FOSS projects.

References:

[1] http://www.linux-foundation.org/weblogs/amanda/2008/02/17/hey-jonathan-the-l-in-lamp-is-literal/
[2] http://www.linux-foundation.org/en/About

mmap_min_addr setting may mitigate vmsplice exploit

2008-02-14T14:43:26Z

Rafal Wojtczuk of McAfee Avert Labs posted an interesting analysis of the "qaaz" exploit for the recent vmsplice vulnerabilities.

Since 2.6.23, it has been possible to prevent applications from mapping low pages (to prevent null pointer dereferencing in the kernel) via the /proc/sys/vm/mmap_min_addr sysctl, which sets the minimum address allowed for such mappings.

So, if you have a recent kernel still affected by the vmsplice issue, try:

echo 65536 > /proc/sys/vm/mmap_min_addr

(If it is not already set, of course).

If using SELinux, the system must be running in enforcing mode.

Note that there was a bug in the mmap_min_addr code until 2.6.24-rc5, although I do not believe it affects mitigation of this particular exploit.

Generally, it is a good idea to have mmap_min_addr set, although it is disabled by default in the upstream kernel as it can affect a some applications (e.g. users of vm86 mode such as X).

As SELinux is able to selectively enforce the setting via policy, it can be enabled for the general case on recent SELinux systems. If not using SELinux, processes with CAP_SYS_RAWIO are allowed to bypass the setting.

IBM article: Role-based access control in SELinux

2008-02-14T13:47:40Z

Serge Hallyn of IBM and general kernel hacking fame has written a great article on Role-based access control (RBAC) in SELinux.

The article is also something of a tutorial, implementing a security scheme for a simple store cash register system, with downloads available for a Gentoo-based SELinux from Scratch qemu image; and for standard Fedora 8 systems.

It's great to see these kinds of projects coming from the community!

Using SELinux Kiosk Mode in Fedora 8

2008-01-10T10:26:23Z

Fedora 8 now has support for Dan Walsh's SELinux kiosk mode, or xguest, which he has previously described in some detail.

The good news is that it's utterly simple to use:

Upgrade to the very latest Fedora 8 -- simply ensure you have run:

# yum update

Install the xguest package and necessary dependencies:

# yum install xguest

Ensure you're running SELinux in enforcing mode:

# getenforce Enforcing

Log out from X, and you should see a new "X Guest User" user in the GDM welcome screen:
Click on the X Guest User account, and you will be logged straight into a GNOME session.

The GNOME session will run as a very tightly locked down SELinux account, which can only be accessed via GDM. It is essentially authorized only to surf the web.

PAM namespace is utilized so that the session has private views of shared writable filesystem space (e.g. /tmp), while Sabayon is used to load a custom GNOME configuration.

Any local changes made by the user, such as writes to $home or their desktop settings will be lost after they log out.

Thomas Mraz's PAM SELinux permit package ensures that the xguest account is only active in enforcing mode, to ensure the account cannot be used to attack the system if it is in permissive mode.

Further technical detail may be found in the package's README file.

Where would you use this? Dan has found it useful for family members with various levels of computer skill, while I can imagine that xguest would also be quite handy for things like LUG events, conference booths, training, Linux demonstrations, information kiosks etc.

If you come up with any cool uses, or enhancements, please let us know.

Enjoy!

SELinux mitigates remote root vulnerability in OpenPegasus

2008-01-07T21:42:24Z

According to Red Hat Security Advisory RHSA-2008-0002, a recently discovered stack overflow flaw in OpenPegasus is mitigated by standard SELinux targeted policy in RHEL4 and RHEL5:

... an unauthenticated remote user could trigger this flaw and potentially execute arbitrary code with root privileges. (CVE-2008-0003)

Note that the tog-pegasus packages are not installed by default on Red Hat Enterprise Linux. The Red Hat Security Response Team believes that it would be hard to remotely exploit this issue to execute arbitrary code, due to the default SELinux targeted policy on Red Hat Enterprise Linux 4 and 5, and the SELinux memory protection tests enabled by default on Red Hat Enterprise Linux.

The enhanced memory protection tests in RHEL5 contribute here to mitigation.

On a related note, Mark Cox has just published an updated grid of vulnerability and threat mitigation features in RHEL and Fedora. Fedora 8, being the most recent distro listed, has the greatest number of these features.

Btw, for those able to attend FUDCon in Raleigh over the weekend, there will be a few SELinux folk around to answer questions, listen to feedback etc.

Update:
Someone asked for more Fedora-specific information to compare with other distributions. Here's a well-maintained page on Fedora Security Features.

SELinux mitigates HPLIP vulnerability

2007-12-19T10:24:16Z

I missed this one at the time, but a member of the Red Hat security response team just pointed me at this RHEL advisory from October, where a vulnerability in HPLIP was mitigated by standard targeted policy.

That is, SELinux provided zero-day protection against local users exploiting this vulnerability to run arbitrary code as root.

Previously:

FOSS.IN/2007 Wrapup

2007-12-14T13:45:42Z

I'm finally back from FOSS.IN/2007, although my body clock seems to be lost somewhere in the Arabian Sea.

The push to make the conference more contributor-focused seemed to work very well.

The final talk slot, which was given to Rusty on short notice, included an invitation for FOSS developers to come down and stand on the stage. First, people who had contributed code to a project -- way more people than anyone expected -- stood up and came down. Then, progressively, people who'd submitted a bug report, or written documentation, or helped others, and finally, anyone who'd used FOSS. Here's what it looked like:

Photo by Jim Grisanzio

Members of the then non-audience passed the microphone around for some ad-hoc lightning talks on what they were doing.

Following that, Atul spoke about the future of FOSS contribution in India, explaining that FOSS.IN would not move around the country, as it is preferred that each region develop their own event. Organizers of other Indian FOSS conferences provided brief overviews of each, including the entirely student-run FOSS Meet@NITC in Calicut.

It was a great ending to a great conference, and overall, simply refreshing to see so much grassroots activity.

An older attendee wrote a nice email to the conference mailing list with some interesting observations, such as "You are prime-movers of modern India" and "Some had weird hairstyles". Indeed, as has been noted by others, including Simon Phipps, there's an intense enthusiasm for technology in India which I've not seen elsewhere.

I really would not be surprised, within ten years, to see India become the top FOSS contributing country.

As a foreign speaker, I found the conference to be a great opportunity to spread knowledge in a direct way -- beyond what is possible via code, documentation, blogging etc. -- and can highly recommend it to others. Rusty had fun, although he definitely under-assessed his final talk.

If you've ever wondered what it's like to return from your morning coffee run to be serenaded by a Nadaswaram, "the world's loudest non-brass acoustic instrument", here's a video starring Andrew Cowie, Spot Calloway and the omnipresent Rusty as part of the audience.

FOSS.IN/2007 slides

2007-12-07T09:11:22Z

I've now completed my talks at FOSS.IN, and posted the slides online (they'll also be available from the conference site soon).

How and Why You Should Become a Kernel Hacker (PDF)

The State of Security Enhanced Linux - (PDF)

Both talks were well attended -- I think about 500 for the kernel talk, and 100 for the SELinux talk, with lots of good questions and post-talk hallway discussions.

FOSS.IN/2007 Photos

2007-12-05T18:48:32Z

I've started uploading a conference photo set here. Expect to see more soon. You can find many photos by others by searching flickr for the tag "fossin2007".

e.g. http://flickr.com/search/?q=fossin2007&w=all

Jet lag is fun, as always -- I didn't think it'd be so bad traveling from Sydney instead of Boston, but it's possibly worse. Thankfully, there is no shortage of strong coffee in Bangalore.

FOSS.IN kicks off

2007-12-04T07:51:20Z

The FOSS.IN project days have commenced, ahead of the main conference. It's great to be back in India, and to meet up with everyone again.

Rusty and I were walking around Bangalore yesterday, and encountered a family of monkeys crossing the road.

(video in case the embedding doesn't work...)

NSA Security Guide for RHEL5

2007-11-29T22:09:37Z

The NSA have published a 170-page security configuration guide for RHEL5. It's a kind of best practices document for security, with step-by-step explanations for locking down pretty much every feature of the OS.

I'd say this is essential reading for anyone deploying RHEL or similar (Fedora, CentOS etc.) distributions, and likely also quite useful in the general case.

Seems like ideal reading during travel to FOSS.IN :-)

Less than a fortnight to go...

2007-11-21T04:57:11Z

FOSS.IN/2007 looks to be shaping up well -- here's the shortlisted schedule.

The live registration stats are interesting -- 57% of delegates have indicated interest in the Fedora session of the project days.

I'm honoured and very happy to be returning this year to give talks on general kernel development and the state of SELinux. While preparing the slides, I was surprised at how much has happened in SELinux since my last talk at the conference in 2005. Things really move fast in FOSS.

It's lucky the talks this year have been extended to 90 minutes, as I have approximately several million slides to get through. Well, perhaps not so lucky for those attending my talks. I'll post the slides after the conference. In the meantime, catch this interview with Dan Walsh on some cool SELinux features in Fedora 8.

Something that may be of interest to others visiting India for the conference is the excellent Foreign Speaker HOWTO by Harald Welte.

I'd echo his advice to always have small change on you (in denominations of 20/10/5 Rs and some coins), as 500 Rs notes are not very useful for local transport and similar, unless you like the idea of giving 10000% tips. It's probably best to obtain the currency before getting to India, which typically needs to be ordered ahead of time.

Uli on SELinux; Hemispherical Shifts

2007-10-10T14:44:02Z

Ulrich Drepper features in a video in the latest Red Hat Magazine, explaining how to play nicely with SELinux.

One of the common issues we see is breakage of third party applications, where they ship with dangerous bugs in the code, which SELinux will often find. These can be coding errors, such as not closing files on exec, where child processes will inherit the parent's, or also commonly, linking issues, where the application has not been built correctly. In the latter case, you will typically see some probably unexpected memory-related security checks failing: Dan Walsh has written about this in detail recently.

Ulrich mentions another common issue, where the application simply has no policy written for it. One approach for this is to run the application as an unconfined domain, which of course doesn't help secure the application itself, but ensures that the rest of the system retains its SELinux protection.

Ideally, the application should have a policy, and Ulrich mentions efforts in education and training to help people better understand this area, as well as improvements in SELinux tools (setroubleshoot) and the development environment (e.g. modular policy).

Another approach that I would suggest, which should be highly effective, is to post details of your application to an SELinux mailing list (fedora-selinux, the main list etc.) and ask for help. In the meantime, you can run the system in permissive mode, which will ensure that labeling is still enforced, and that you can observe the logs for further analysis if required.

Ulrich also mentions more policy being developed internally for packages, with increasing support for user-oriented (as opposed to server-) applications.

***

Some will know that I've recently moved back to Sydney, where I'll be working in the same role with Red Hat. Linux in the Asia-Pacific region certainly seems to have grown since I left four years ago, as evidenced by the size of the current Sydney RH office compared to the fairly small one I visited then.

They have one of the most amazing views I've ever seen in Sydney, stretching from the harbour around to the Blue Mountains. Of course, my tiny camera & lack of skills cannot do it justice.

On a clear day you can see New Zealand

It's really exciting to be back.