Slashdot Mirror
HP-LX 1.0 Secure Linux
kengreenebaum writes: "Webtechniques has a short but interesting article on HP's approach to a secure but expensive LINUX distro. Basically they started with RedHat 7.1 and added compartments; an extension to the age-old chroot jail concept where the processes representing major services run. Kernel extensions allow HP (or the administrator) to specify which compartments can access which kernel resources including individual files, network stacks, and each other.
HP has
Technical Product Brief as well as other material online. Interesting to compare HP's approach to that of the
NSA's Secure Linux
projects. These concepts sound like a solid way to prevent buffer overflow type security holes in individual services from compromising the entire machine. At $3000 HP-LX is too expensive for many to experiment with but the NSA's code seems to be more readily available. Anybody have experience with these distributions or with similar approaches to Linux security?"
I'd just like to comment upon the NSA's Security-Enhanced Linux project.
It is certainly more accessible, and I've prompted my company to look into it. Considering the current political environment, I believe this is a good way for small consulting companies to distinguish themselves.
"Why, yes, Mr. Customer, we are very familiar with computer security and specialize in using products developed by the National Security Agency. If it's good enough for the NSA, don't you think it is good enough for your business?
Doesn't HP have to release their source code to comply with the GPL?
Shh.
I installed their distribution and it works fine, except for the GUI login which says "Welcome to wiretap029114.nsa.gov". How do I change it back to "localhost.localdomain"?
...here.
b&
All but God can prove this sentence true.
In the article they mentioned programs use authentication based on ssh private keys. This is all fine and dandy, but what about doing this for $0 rather then $3000 and just kerberizing your own apps. Then you can have total control over more than just some of the admin functions, plus you start off with a nice base for more infrastructure later.
- Buffer overflows and improper argument checking plague every modern
UNIX kernel. Think about the recent sysctl() input validation hole in
Linux. Or the recent
/proc bugs in FreeBSD. Or the LDT handling bugs in
NetBSD, Solaris, and many others.
- Most kernels were not designed with least privilege in mind. For
instance, the mount() syscall allows ordinary users to mount and umount
filesystems. Access checks are performed (to make sure it is mounted
nosuid, and such) but there are undoubtedly holes waiting to be discovered.
- Until only recently, Linux had several bugs allowing users to
commandeer each others' shared memory segments. This could be used to
corrupt memory used by init(1) and several other critical programs, causing
a major security breach.
- Because the X server needs low level hardware access, most OS kernels
allow access to iopl(2) and ioperm(2). This means that attackers can talk
directly with the hardware, bypassing the OS security. The alternative, of
course, is to ban the use of graphical interfaces on that system; but
usually that is unacceptable.
Although these issues can all be addressed, the problem of proper kernel security is at best a "whack a mole" situation in which a new hole will arise shortly after an existing hole is patched. Thus, the HP-LX software probably isn't worth the CD it is pressed onto.vw
Over the next couple of years I saw high level managment with no comprehension of the Unix/Linux/GNU world whatsoever do some very strange things. The HP environment is rife with strange little tribes that lie and steal from one another with no real reason. Their Linux community is no different.
And as far as HP contributing to the open source world - don't count on it. They will happily steal code, re-write it, and release it binary-only if they think they can get away with it. I've seen them do it. The whole damn company has a prima-donna attitude and will do pretty much whatever they think they can get away with.
And as far as HP and security go - take a look at their own damn HP-UX OS for a security model and ask yourself why they think they can release a unique and decent secure linux product if they can't even release their own OS with any semblence of security?
...whatever happened to that commitment? I mean, were there any technical or (and) historical reasons for choosing Red Hat, or is that yet another instance of choice by misinformation or herd instinct?
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Youre right, but whoever buys it is then free to do whatever he wishes with it, including give it away, sell it for less (or for more), or print it out and use it for napkins. So whats the point of HP selling it when all they have to do is make one sale, then the buyer could turn around and give it away to thousands of people? They cannot stop this from happening, because the code must be GPLed, and the GPL allows that.
Liberty in your lifetime
HP is dumping HP-UX, and will be moving people to Linux...no one ever listens...
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
I've been developing some firewall products and distributed IDS nodes based around NSA's secure linux kernel and tools. Takes some time to get used to, but the marketability plus just starting with a base that's been *really* hardened is a pretty nice combo on an already good thing. John
Typical slashdot ranting about gpl violations and how this is nothing new etc.. I wonder if anyone even read the article.
This is much more than just a few kernel modifications but rather a full distribution that comes on 4 cd's. Instead of just having some hacks that improve security the whole distribution is build from ground up with security in mind.
For example: You can't access shell unless you're on a console or use ssh. You can't access the configuration tools unless you are in posession of administrators private ssh key. Also, the installer forces you to set the system up with security in mind instead of installing everything and the kitchen sink..
Best part of this is that it comes with support from a highly reputable vendor. Sure it has it's price tag but imagine the amount of work required to make a full distribution that's security conscious and backing it up with hp's name!
And yes, you can download the source code that goes into kernel..
As a practical matter, it may help a lot because it makes the machine different from other Linux machines. It may be not too hard conceptually to work out how to break through this kind of security, it will likely protect systems from common exploits of common bugs.
However, in the long term, the only solution I see to security problems is to build on foundations that have support for guarding against common bugs and analyzing security-related program properties. That means, among other things, using languages with built-in default checks for buffer overruns and using languages with type systems that can be used to verify that data doesn't get where it isn't supposed to get (Perl's notion of "tainted" is a simple runtime example; similar static type checking is also possible in some cases). Decades of UNIX, Windows, and Linux software development and bug tracking have shown that without such support, even skilled programmers simply cannot write software containing very serious security problems in actual releases. In different words, the Linux and Windows kernels and daemons will have to be rewritten in something other than C or C++. Sorry.
There's a missed point in discussing whether or not HP-LX is practical or whether or not it's worth $3000. HP's target market is and always has been big businesses. What they've done in providing a secure, robust Linux implementation is to take away IT manager's number one fear about Linux: that's it's somehow "insecure."
Practically speaking, it's safe to assume that nobody is going to run out and nuke HP-UX 11 off their servers in favor of this - HP-UX is still very far ahead of Linux (and some of its competition) in several important areas. However, for IT managers interested in considering a partial migration to Linux, this gives them a stable and secure path on which to begin to venture down, and undoubtedly one that's also covered by their existing support contracts with HP.
Charging 3000$ for the CD set means that 99% of the jackasses who would use the GPL in order to buy something and then turn around and release it for free can't afford it while the 1% that can have to pay a pretty penny to be jackasses. I can pretty much assure you some jackass Linux zealot with no understanding on the GPL is sitting in his bedroom right now trying to figure out how he can raise 3k so he can be a folk hero by releasing the code an evil company is keeping secret. At the very least HP is giving some idiot something to do.
I'm a loner Dottie, a Rebel.
At $3000 HP-LX is too expensive for many to experiment with...
That is only if you're afraid to do a little kernel hacking. Unless it's a binary only module (I doubt it, the're not hiding info about hardware) kernel patches should be available for Free. And really, $3000 beans isn't a whole lot for what sounds like a dreamy setup for internet boxen serving holy DNS and FTP. This is how internet services really should be ran by default. Unlike IIS that runs as user profile SYSTEM so that it can do impersonation (sorry for the M$ dig, but it's a really good example of how not to run internet services).
The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.
On a server? I never install X, too many performance and security trade offs.
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
The user-mode component is not GPL, but given the kernel API, it's pretty easy to make up the user part.
Bruce
Bruce Perens.
Uh.. How about you go download the GPLed code from hp's site right now instead of speculating about what people could do.
However.. You are not going to get the closed source administration tools without which the kernel mod's are almost worthless. You also don't get a fully set up distribution with all the configuration and will have to duplicate all the effort that went into creating it.
If you want to be reasonably sure that your version is secure you'd have to perform extensive testing on it and have a lot of really smart people take a look at it. This is actually the easiest part as it follows normal linux development method. Still, whose ass is on the line if things are not as secure as they should be?
And you can bet your ass that anything that doesn't need to be GPLed is not and it comes with a very strict HP license that specifically forbids any disassembly, resale, etc.. Support contracts probably also include a clause that you have to have purchased the official hp distribution..
The fact that SELinux (NSA's system) now uses the LSM framework means that it can be extended easily. You can either extend the SELinux modules or add further LSM modules of your own.
It should be extremely trivial to provide a complete, and more flexible, clone of the entire HP security framework inside LSM, as all you're really doing is providing a set of capabilities to each thread, with pre-set defaults.
In fact, you'd probably want to exploit SELinux' existing framework for this, so that you could create pre-set defaults on a per-user/per-login-type/per-thread basis.
All in all, HP's setup doesn't sound novel enough to be worth 3K, but does sound intriguing enough to copy. Which, really, is something the LSM guys seem to already be doing. They've ported a decent portion of the OpenWall framework, which does a lot of this kind of stuff already.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I've heard at least one or two people here worry about HP's security in HP-LX (and HP-UX) and I have to say this: anyone who depends on their OS as the primary basis of security - at least in this day and age - is not properly looking at security in the first place.
If you are (or were) a network admin, would you host an Internet server without a firewall just because you used one OS and not another? I don't think so. Total security involves additional layers on top of the OS - firewalls, requiring passwords for many or all access points, and so on - as well as an admin that keeps up to date on security holes and works to plug them.
That's not to excuse OS developers who leave their products ripe for abuse, but so long as reasonable steps are taken as part of the OS I wouldn't be slandering its maker - that is, unless they're promising something they know they can't deliver.
- "Never let a computer tell me shit." - DelTron Zero
Not installing X doesn't cause the kernal to take note, and alter how it treats the system calls in question.
Vintage computer games and RPG books available. Email me if you're interested.
Kernel bugs aren't the big problem though. Look thru bugtraq and see what the kernel/user-app ratio of security problems is.
Now look at how many of the kernel level bugs that are remotely exploitable. (Ummm, I mean exploitable from remote, not that they're unlikely.) Not to say that local problems aren't problems too, but they're a lot easier to manage.
You're right about the bug whack a mole, but this time you'll be playing on a table with most of the moleholes plugged.
The X thing is a bit of a red herring. The problem is that it has hardware access (disregarding fbdev and stuff like that), and hence (from a security POV) could almost just as well be part of the kernel. Solutions:
- Don't run it. And don't allow other processes the priviliges it would/could have had. (This is easy with any MAC and even DAC system, X is always a bit of a special case.)
The Selinux system is very fine grained and you can grant a subject a capability or not depending on its' type.
- Compartmentalize X itself. To some extent this is getting worked at, but not (mostly at least) for that reason.
(X apps are a little different from other apps, since they have other IO options (Atoms, cut+paste buffer etc.) Look up CMW (Compartmented Mode Workstation) if you want to get into that.)But even if you can't do a thing about X, this is still worthwhile. Think about someting like xntpd. It's root because it needs to open a low port and because it needs to be able to update the system time. But there's no reason that it needs to be able to, say, mount filesystems, read protected files, or load kernel modules. with traditional unix security we can't do that, but with this stuff we can. The attutude that "because it only fixes 99% of the problem, it's not worthwhile" has been a problem long enough.
"An object declared as type _Bool is large enough to store the values 0 and 1." -- 6.1.2.5, C99 standard.
The Confused Deputy will stay confused, no matter how sophisiticated the ACL's are.
The only real approach to security is a pure capability system, and ofcourse the combination of pure capbility systems with safe languages.
The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.
The real way of doing this is putting the hardware drivers into the kernel (frame buffer devices).
No user process is supposed to access hardware directly, and if that meant we have no graphics, it would also mean no keyboard, text, or sound.
Although these issues can all be addressed, the problem of proper kernel security is at best a "whack a mole" situation in which a new hole will arise shortly after an existing hole is patched. Thus, the HP-LX software probably isn't worth the CD it is pressed onto.
That may be true, but it is only because of the nature of UNIX kernels. Kernels built with the principle of least privelege in mind (such as EROS) are definitely worth the fix, as it is quite unlikely to present new holes (and such a design is quite unlikely to have many holes in the first place)
RSBAC is Secure Linux Done Proper (or almost there).
Castle from ALT Linux Team is a Linux distribution that uses RSBAC and chroot jails. Also, recently, the tcb scheme has been adopted for secure access to system passwords without need for setuid root.
My exception safety is -fno-exceptions.
You know how PHBs think: If it's free, then you can't make money off of it. If HP is able to sell this at $3000 a piece, maybe they will get their eyes opened for the possibility that there is money in Free Software.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
HP-LX is an unfortunate shorthand name for this product, since "HP-LX" is a widely used to refer to HP's excellent (but discontinued) line of DOS based palmtops - HP 95LX, HP100LX, and HP200LX. It appears from the technical brief PDF that the official name is "HP Secure OS for Linux". Perhaps some other name could be used to avoid confusion, like "HP-SLX" (secure Linux).
For more information on the LX palmtops, see the FAQ at http://www.hplx.net/faq.faq.html. Attached below is a short excerpt from the FAQ that provides some background.
---
Q. What is the HP100LX?
Depending on your point of view, it's either an IBM PC-XT stuffed into a very tiny case with some Personal Information Management (PIM) software and Lotus 1-2-3 built into ROM, or it's a high-end electronic organizer that also runs MS-DOS software.
Q. What is the HP200LX?
It's the successor to the 100LX. It's essentially a 100LX with cosmetic changes and the addition of Pocket Quicken, LapLink Remote, and some feature enhancements for the PIM applications in the ROM.
Q. What is the HP Omnigo 700LX?
It's basically a somewhat faster 200LX with a docking cradle for a Nokia GSM cellular phone, some LEDs on the front, and some extra built-in communications software. It is only available in Europe and Asia/Pacific, where the GSM standard is, well, standardized. This product has been discontinued by HP and is no longer sold. If you can get a used one, it's possible to use it in the US if you live in an area where GSM coverage is offered (i.e. California, Nevada, etc.) if you get a compatible phone. The Nokia 2190 fits the OmniGo 700LX's cradle and works in the US, for example.
Q. Why would I want an outdated DOS palmtop when I could get a modern Windows CE machine?
The 200LX may be a few years old, but it is a far better computing device than any Windows CE machine. A few of its strengths:
- Battery life (up to 2 months on a single pair of batteries)
- DOS compatibility (can run millions of programs written for desktop computers)
- High-resolution screen (fully CGA compatible, 640x200 [33% wider than most WinCE units])
- Better keyboard (separate numeric keypad; nice solid feel with good tactile feedback)
- Better PIM apps (built-in apps are unsurpassed for quality and ease of use)
- Pocket Quicken built in (keep track of your finances without spending any extra money for the financial software)
- Better expansion support (see flash cards and other memory expansions as a drive, not just a folder)
Q. Why would I want an outdated DOS palmtop when I can get a sleek PalmPilot or Palm III?
The PalmPilot series is made for a completely different purpose than the 200LX. The 200LX is essentially a full-blown computer that fits in your pocket, and doubles as an organizer. The PalmPilot series are meant to be organizers and to help connect with desktop computers. Both platforms have their strengths and weaknesses, but for real computing in the palm of your hand, the 200LX is the only choice.
---
The two OSs are fairly similar in what they hope to accomplish -- isolate the risky software and users from the rest of the system so if something bad happens it doesn't take everything down. From the sound of the HP presentation, this is all HP Secure Linux does. You create compartments and then specify what the compartment can do. You can do the same thing with the NSA's SE Linux and much much more. I was really impressed with the flexibility offered by SE Linux. You can setup your system with about any security policy you like. The biggest problem is the great complexity. You need to do a good deal of research before even thinking about modifying the sample security rules that come with SE Linux. There are thousands of rules in the included security policy. This is where HP Secure Linux probably has an advantage--it's a bit simpler to user. Though I haven't had a chance to try it out yet.
You don't really need to pay $3000 for it either. The kernel patches are GPLed and part of the kernel security interface used by SE Linux also (NSA and HP have cooperated here). You are really paying for the tools, but those are just programs that make certain sys calls. It shouldn't be a problem to write your own open source versions. Though there might be a nice gui that would take more work to create.
If you are interested in secure linuxes also take a look at Immunix and EnGarde. Both also have kernel level security controls, but not to the level of NSA Linux. Immunix has a comparment system like HP Secure Linux called SubDomain. EnGarde uses the Linux Intrusion Detection Project.
A paper doing a detailed comparison of the four would be welcome!
- Complexity and Flexibility: The more complex a product is, the more flexible it can be. SubDomain is less complex to manage than SELinux, but offers more flexibility than HP-LX.
- Price: SELinux is free, Immunix Systems are $90 each, and HP-LX is $3000 each.
Immunix also features other security protections:- StackGuard: resists most buffer overflow attacks.
- FormatGuard: resists most printf format bug attacks.
Crispin----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase
What's most important about the price tag, is that HP is backing a secure version of Linux. It's not really 3K for some fancy GUI tools, but 3K for the tools and for HPs guarentee that this is actually going to work.
:)
It's not really that expensive. In fact, I'll probably recommend it to the company I work for. If your company is security conscious, and you don't want to have to maintain something, then this seems like a great option.
This is probably one of the first really good business plans I've seen with Linux. The greatest part is that HP didn't try to mess around and not release the kernel stuff. So, they've helped out the community by adding a cool concept (I always hated that Linux does have jails) and they also are delivering a good, reasonably price, product.
I am of course assuming that this software works
If you do the math though for a server running Windows NT plus an email server, web server, and remote admin package that would be as robust as what Linux has, then it's a no brainer which one is cheaper.
Especially since alot of software is based on the number of users (especially email suites). So you kind of end up getting screwed when you hire more people.
int func(int a);
func((b += 3, b));
Well, in your situation, Party A wrote the software, they can do whatever they want with it. In other words, party A has to be the one to put the GPL on their own code. If they do, then they are obviously pro-freedom. If they don't, then the Code isn't GPL'd. In other words, everyone has distribution rights for GPL'd code.
If party A just modified someone else's code, a-la the linux kernel, then gave out the software with a special contract not allowing distribution, then they would be violating the GPL. Which would mean that by distributing the code that they modified they would be breaking copyright law, and Linus or anyone who contributed to the Kernal could "DMCA" their ass, so to speak.
autopr0n is like, down and stuff.
In my opinion (as a practicing Head of Information Security and a former Security Architect for a number of kernels) what Linux really needs are capabilities (which we have, we just need to start using them by default) and a functioning audit subsystem. A functioning audit subsystem does not compromise only the kernel part, but also the audit compression/reduction facilities (normally done in user space) and the tools to define what events to audit and tools to search and securely store audit trails.
Audit trails that can be (semi-) trusted is what most of us security people demand, and which Linux doesn't deliver (don't tell me about syslog, as it is designed for IT administrators, not security administrators).
These seems to be present in the HP-LX (can't access HP's website right now, but I assume it is based on the old SecureWare code HP purchased a while back and been using the last couple of years). Unfortunately, what Bruce (Perens) says about that it would be easy to reconstruct the user space parts of the auditing subsystem I disagree with, as this is the majority of the code and also the most complex part.
With Best Regards
Roland B.
-- Roland Buresund MBA, MCMI, CISSP
Much of the work is to be rolled into a future FreeBSD distro. And that's released under the BSD license -- than which you can't get much less restrictive.
Bruce
Bruce Perens.
For example, a mail handler should be composed of several components in separate security compartments:
That's what NSA Secure Linux is intended to support. DoD secure systems have been built like this for at least two decades.
Again, and I cannot overemphasize this, the key is that the trusted components must be small. All other architectural considerations, including performance, must yield to this if you want security.
Call me on this if I am wrong here, but is the major factor in spending $3000 on this gem of software is chroot jails (or a reasonable facimile)? The article was rather brief, but from the look of it, aside from that feature - which the article even admits is not new - we have one other feature, that it is "secure by default". Well, does it keep you from installing Telnet ever? What about the Berkeley R-tools? The SSH root admin thing looks clever at first, but how many places have you worked at where the same root password was used across multiple boxen - even those of different OSs? Now, how much do you want to bet that the password over the SSH key is going to be the same, or similar, to the password for root itself in most installations? How is this any different than simply having a second login prompt for root?
Look, I'm sure someone else has said this already a million times here, and I know Bruce Schneier makes it his mantra, but I'll repeat it for those of us who came late: Most of security has nothing to do with software, and everything to do with poor procedure. All the chroot jails in the world cannot restrain the sheer magnitude of people's apathy toward secure practice and process.
And yes, sometimes even the best security is broken. Let's face it, if you want your data secure, you are already outnumbered millions to one. Yet, this is a default condition - the majority of security vulnerabilites are relative to the actions of script kiddies, who use network flooding and other lame attacks to force people off the net and crash systems. Adding another security layer will make it harder to brute-force your way in, certainly, but what's the point of sealing the door with concrete if lazy administration practice leaves the windows wide open?
And, how does this differ from OpenBSD? I'm not a BSD zealot, but way too much of this sounds like the exact practice taken toward OpenBSD development. Does this software deserve extra creds because it costs more? Are people more likely to take security seriously if they spend $3000 on an operating system than if they get it for free? How much of this code is audited? All the default packages? Did they audit anything, or did they just implement chroot jails and assume they have found a "workaround" for a malignent problem in UNIX security?
I'm not saying that this is a bad idea. I'm sure this distro will provide for a more secure environment by default, for those of us who don't have the time to audit our production boxes. But I just don't see reason to presume that this distro is any more secure than a properly configured SELinux or OpenBSD box. And please, if you think I'm wrong, enlighten me, because I'm no expert. I just think that building a better mouse trap is pointless when the trap operators don't know how to operate it.
Know ye not that ye are Gods???
Because of all the labor and brain work involved. This a VERY good thing for shops and ISPs that standardize on HP to do.
In the SE Linux built against 2.2, PSIDS were stored at the inode level, which meant that a security resolution below the filesystem level was only possible using ext2.
The latest versions use the Linux Security Module (lsm), like LIDS, that hooks in at the VFS layer. so far, ext2 and ReiserFS have been confirmed to work. The only requirement the fs is persistent inode labelling(?-my terminology is off-?), but (IIRC) ext3 and xfs have also been tested.
Check the mailing list for details.
First some clarification.
HP-LX has no VirtualVault code. There is nothing in HP-LX code that is derived from VV.
A trusted/secure OS should not be your ONLY security mechanism. It is just a part of the overall architecture.
So, what were the goals of this product:
VirtualVault covered the ultra security needs. But at a cost. You needed to intergrate your applications on a VV. You had to teach your sysadmins about VirtualVault. Many smaller shops could not justify the cost of these. So an alternative was created by HP.
Some form os security is better than no security at all. So, what HP wanted to do is lower the complexity of the security mechanism and raise the ease of use. This would allow people to get applications up and running quick on their machine and not have to retrain their systems on a new os.
So, the product had to be:
1. Help protect services on the network boundry. So, this is not designed as a multi-user system. It is designed to protect any type of service that is made available on a public network.
2. Easy to use. Without this, it would be an interesting product, but acceptence by the non-security folks would be hard.
3. Security should not be intrusive. So, as little code change as possible. By this I mean, try not to make changes to user space programs. The admin should be familiar with the environment that he is running in. Only 2 programs are changed, init and xinetd.
4. Sometimes security had to be relaxed in order to keep it easy to use.
These were the four high level drivers for this product.
From a feature set, there are three major components:
1. Containment. Protecting agains ALL buffer overflow attacks is difficult. So, lets contain the damage. Compartments helps us issolate the application from other applications/subsystems on the system.
2. An audit subsystem to be able to watch what is going on on the system. Collection audit does not help if you can't do anything with it. So, it had to be flexible. It is in it's early stages.
3. Lockdown. This mean, locking down most of the permissions on the system. Use tripwire to monitor what is going on on the system. Turn off most of the service that are needed. Generally, do whatever you would do to lockdown a system that is put on a public network.
This should give a little insight into the motivation for the product. This should help shed some light why some decisions where made. The goal of this product to to find a right balance between "ease of use and security". You can be the most secure product, but if it is difficut to use, it will be cast aside. HP-LX is an attempt to achive this balance. More work is needed, but it is the first step...
Safe languages are languages incapable of expressing things like buffer overruns or overrunning other memory, or invalid array indexing. This means they cannot express corruption of memory and are not volenurable to the vast majority of problems in most things today. Those languages, including Python, Smalltalk, Lisp, Perl, and others are incapable of crashing the machine (although sometimes C modules written for these do crash the machine), yet are Turing Complete and capable of solving any problem C, C++, or other unsafe language is capable of solving.
any ability to write to the accounting files.
If that is considered a design requirement,
then the design was wrong.
But the compiler IS outputting accounting information here.
Its easy to claim that any design requiring a certain feature *nix cannot provide is wrong, but it sounds quite an absurd claim to me. You're trying to adjust the world to your OS, rather than write an OS that fits your needs.
In terms of debug/frequency stats, create a
directory, make the compiler setuid or gid
to be able to write there, and put the stats
and ONLY the stats in that directory (
you do the set(ug)id, at the very end,
just to write the stats file as the last
hurrah.) Or even just leave it public write,
if someone wants to futz with your stats
they really have time on their hands.
Problems:
How is your solution preventing the original problem of a malicious user naming a billing filename as an output file?
As long as the compiler 'changes hats' (Setuid/gid), the privelege-checking is quite complex and will probably result in VERY complex ACL's to achieve the goal.
These stats are used for billing information, and people would thus be VERY willing to mess with them.
All these security settings require root to set up, meaning that only a system administrator is capable of setting up any system involving security checks.
Alternative approach:
The mechanism used to identify (name) objects is that of unforgable, OS-implemented keys called "capabilities". These capabilities are much like *nix file descriptors, but they are never open()'d or close()'d. Having the capability is a necessary and sufficient condition to access the named object, the object does not care who access it.
The above example, is very simply solved by capabilities:
In order to name the billing file to the compiler, the user must have a capability to that billing file. In that case, the user is fully authorized to access this file. Obviously, the user does not have a capability to this file, only the compiler does, and since there is no way to forge a capability (just like file descriptors), the user cannot name the file he must not access, and may not confuse the deputy.
Advantages:
Users (code) can only express requests by access to a capability, meaning that code is only capable of expressing authorized requests. This means that there is no ACL test failure that may give false access to this user, as the mere ability to express a request is an indication of authority to do it.
The only security test required at runtime is that the capability is valid, which is equivalent to the validity test of a file descriptor, nearing 0 time.
Capability systems are in fact simpler systems, and many security properties of such can be mathematically proven, as demonstrated by Shapiro, in his proof of part of his EROS system.
Capabilities have per-process granulity, rather than per-user granulity, and very fine-grained control of which objects every process has access to, thus the principle of least privelege is implemented.
No need for a 'super user' that bypasses ACL's, because that would destroy the principle of least privelege. Every user can create objects and spawn capabilities to use those objects, and distribute them through every channel he has a capability to.
This means any process with some minimal set of capabilities can set up a security system, not requiring any super user to bother, and killing the vast majority of threats involving a superuser.