What’s Not in the IBM Redbook: Apache Users and IFS Security

A few years ago I worked with the lead developer of RJS Software’s WebDocs-iSeries document management solution to see whether we could use authorization lists to provide a standardized method for securing WebDocs-iSeries objects on the iSeries.

You see, the iSeries is strange in that it has two file systems that are both “native”, and WebDocs-iSeries uses both. The first and the original, is the library/object model that has been around since the early System/36 days. A master library, QSYS, contains system objects and all other libraries, which may themselves contain objects but not libraries. This produces a very flat file structure, with any object being fully specified simply by naming the library it is contained within and its object type.

Later, a UNIX-like file system was added (IFS or Integrated File System) but without removing the old file system; instead, libraries appear as UNIX directories with objects appearing as files and object types their extensions. Native applications were blissfully ignorant of the change, and I’ve actually spoken to administrators who were similarly ignorant. In addition, many iSeries applications do not explicitly work with the IFS.

With V5R3, IBM switched from using its own web server on the iSeries to using the popular Apache web server. Before that WebDocs-iSeries had been storing the actual documents uploaded to it in the IFS, so any comprehensive security solution was going to have to accommodate the library/object model as well as the files and directories in the IFS. Authorization lists fit the bill perfectly.

redbooksOr so we thought. Ultimately, they proved too cumbersome for our customers and their real-world utility was minimal. But along the way I stumbled across an odd mismatch between the level of authorization that was theoretically required for Apache in IBM’s Redbook and what was actually required.

Apache on the iSeries has two primary user profiles it uses: QTMHHTTP and QMTHHTP1. The former is used for accessing the web site pages under /www for a given Apache instance, while the latter is used for executing CGI programs. Since the same iSeries job may be used for both operations, Apache switches the user profile of the job when it runs CGI programs.

What this implies is that the only files QTMHHTTP should ever need access to are those in /www. But, in fact, it traverses the directory structure of the IFS to check whether a given CGI program is present before the job switches users. Since our CGI program object is in the RJSIMAGE library, QTMHHTTP needed read access to /QSYS.LIB/RJSIMAGE.LIB/* before it would perform the switch and allow QTMHHTP1 to run the program.

While unexpected, this mismatch between expectations and actuality isn’t necessarily a problem. But paying attention to such mismatches can be educational. The Linux From Scratch project has actually made a sort of perverse game of this form of pedagogy, with their “User Based Package Management” approach. It looks masochistic because it is, but it’s also enlightening: verifying security is all about attention to such details.

Last I checked, V7R1 behaves the same way, and the Redbook still hasn’t been updated. So it goes …


Watch and Learn: Security Metaphors

In case you weren’t able to attend Secure360 this year, you can catch the presentation that Josh More gave entitled “Security Metaphors” right here.

Here’s the original description of the presentation:

There is a divide between the so-called “security/technical” people and the “business” people. We’ve all heard about how we need to “speak the language of business” and “get soft skills” to succeed. However, even after decades of trying, the divide still exists. Why does it seem that we never make progress? Are we truly not improving? Is the goal receding as we chase it?

This presentation posits that we’ve been making a fundamental error in trying to explain things to people outside our field. One thing that people-oriented people do naturally, and technically-oriented people do not, is communicate with others using the target’s metaphors. By taking this approach and translating issues into different frames of reference, more time is spent exploring the issue instead of arguing over why it matters.

By focusing first on being understood and second on the specific issues, rapport can be built and, over time, you can get the resources you need to win more battles.


On Tigers and Teams

As many of you who read this blog know, in addition to doing security, I also like to go to zoos and take photos. (You can see my work here.) It is rare that this hobby overlaps with my life in security, but once in a while, it does. In May, I was in Washington, D.C. for a Sophos conference. After the conference (as one does), I went to the National Zoo.

I got there before opening and was taking photos. I saw these signs…

DSC_7356 DSC_7357 DSC_7358

… and made a quick joke about the zoo not wanting people jumping in to pet the tigers. Then, however, I saw this, and everything changed:


Read more…

A Security Lesson from the Dinosaurs

Last week, I got my copy of All Yesterdays (not the used Amazon versions, as the pricing algorithm is failing hilariously). I’ve been a fan of Darren Naish’s work since I discovered Tet Zoo years ago. It turns out that in addition to writing amazing articles on the cladistics of extinct crocodilians, he is also good at writing about paleo art.

camarasaurusYou might think that paleo art is art done by prehistoric people, but no. In this case, it is art done to provide imaginative reconstructions of life from fossils. I imagine that most people these days are aware of the belief that many of the two-legged dinosaurs were feathered. However, as it often turns out, things are more complex than that. This book explores the history of dinosaur art and, along the way, draws on what we know about natural history, camouflage and mating habits of contemporary species.

So why am I posting this review on a blog that is (more or less) focused on information security?

Well, in addition to this book being about pretty pictures of dinosaurs, it is also about an industry working over time to make guesses about the truth, analyze their mistakes in the face of new evidence and, through a constant stream of screw ups, come closer and closer to consensus. As they’ve done this, everyone has had to constantly adjust to the shifting truth.

In effect, it is a book about evolution … the evolution of species … the evolution of understanding … and the evolution of the understanding of evolution, so to speak. This happens in all industries, but the younger the industry is, it seems, the less we like to acknowledge that we don’t have all the answers. In Information Security, we don’t like to be wrong and we particularly don’t like to be wrong in front of other people. This is understandable, as when we make a mistake in security, people could get hurt. However, when we don’t get a chance to discuss our mistakes as a community, we don’t get a chance to improve.

Today, there is some discussion in the community, but mostly within closed mailing lists and at conferences. Unlike in the realm of paleo art, our mistakes tend not to be public, so there are fewer eyes on them and fewer opportunities to get better. Fortunately, there are more hackers than professionals who draw dinosaurs, so we do get an advantage of numbers. Still, there is ample room for improvement.

This book explores the problems that arise from:

  • Taking a superficial view of evidence
  • Not comparing logical conclusions to examples of modern data
  • Avoiding analysis and basing beliefs on the misguided work of others
  • Looking strictly at hard evidence and ignoring behavior
  • Hyper-focusing on dramatic scenarios

Sound familiar?

Even Superheroes Need Their Tools

Today is a sad, and dangerous day. As you may have heard, Hostess is looking to go out of business. While it is likely that some of their bigger brands (Twinkie, Wonder Bread) will live on, it is the end of an era. While I never personally consumed much of their product line, as my mother would not let me (You can’t have a Twinkie, here’s an apple), I mourn with the rest of my generation over the loss.

However, unlike the mainstream news media, I am also deeply concerned about the fate of others in the wake of this decision … specifically due to the lack of Hostess Fruit Pies!

See, I remember when The Flash used them to save the city from the Bureauc-Rat. They were an essential tool for Captain America in preventing alien invasion. Aquaman used them to stop a shark invasion. Iron Man’s technology alone wasn’t enough to foil a bank robbery. And Spider-man used them to prevent the destruction of homes. In fact, there have been over 200 times that Hostess has helped save people.

Without this powerful tool, how will we ever survive?

Fortunately, most of our super heroes have contingency plans. DC heroes team up to become the Justice League to solve big problems. Marvel heroes team up to form the Avengers, first fighting among each other and then solving problems. Even the independents work up a good crossover now and then when they have to.

The question is, do you?

In IT in general and in Security in particular, we are highly dependent on a complex web of relationships and dependencies. This can be as simple as needing Microsoft to release their patches so we can protect ourselves. (Which you should do, as this month’s fixed some important issues.) Or it can be as complex as having systems dependent on Dell’s management appliances which are dependent on third party technologies.

Do you know which technologies you are dependent upon? How would you react to their sudden unavailability or to a problem in their supply chain? Do you have a contingency plan or will you have to figure things out in the moment?

Sadly, most people I talk to are in the latter category.

When you choose your vendors, it’s not enough to know if they can do the job today. You also have to know if they’ll be there for you tomorrow and to have a plan in case they’re not. All too often, I see companies who waste far too much time assessing vendors based on the “ideal” technology and no time at all looking at how it integrates into operations and loosely-coupling their technology to other systems.

I’m constantly visiting companies with networks that employ expensive technologies that don’t meet my clients’ needs, while cheaper and better  technologies remain unused. This isn’t just annoying, this is potentially catastrophic to the business. For a case study, look at Hostess. Specifically, look at the strike document. In 2009, technology was not refreshed, which helped to put them into the position they’re in today. Granted, they had other problems. However, whether we’re talking flow-improvement like Document Management or monitoring and control like Anti-malware or UTMs or DLP, technology serves as a multiplier.

If you choose the wrong technology, it will multiply your problems. If you don’t choose the right technology, the firms that do will multiply their profit and leave you in the dust.

When most people hear that we do assessments, they think vulnerability scans and penetration tests. And yes, we do those. However, most of our clients find a lot more value in our vendor assessments, disaster recovery assessments and strategy assessments. These focus on security AND the business. After all, security means nothing without a business to protect.

If Hostess had learned that lesson in their first restructuring attempt, perhaps they’d have lasted longer and a contingency plan of liquidating the entire company would have stayed … a contingency plan. As for me, I’m going to take a long lunch and stock up on fruit pies. After all, you never know when Spider-man might come-a-calling.

And if you haven’t downloaded our very own RJS Smart Security comic book yet, click here!