Slashdot Mirror

Yes, VMS did (albeit DACL's vs. MAC - & yes, there IS a "subtle" difference, that's NOT SO "SUBTLE" actually), and you're correct in citing that since the same man architected BOTH Digital Equipment corporation's VMS & Windows NT...

* Ever notice the "coincidence" that VMS is 1 letter LESS than "WNT" (Windows NT)?

(Odd that, eh?)

APK

P.S.=> Here's how it was explained to me, as to ACL's vs. MAC vs. DACLs, by a Mr. Henry Hertz Hobbitt of securemecca.org, in fact & it IS pretty accurate!

(While I argued that ACL existed on Windows NT prior to MAC on Linux via SeLinux which the NSA "bolted on" to Linux):

---

DACL:

Discretionay Access Control List. I am going to put a premium on that word "Discretionary".

That means you have a choice. Unfortunately, frequently upping DACL control comes at the cost of decreased usability (think of Windows 2003 server versus Windows XP). But in a way, AV is an add-on DACL that restricts what executable files you can run by signature or heuristics.

MAC:

Mandatory Access Control. I am goint to put a premium on that word "Mandatory". That means you do not have a choice. You get it whether you want it or not. Usually increased MAC security can be done with very little cost in the way of decreased usabiltiy.

---

IBM MVS, COS, RT-11 & DOS:

DACLs: NO
MAC: NO
Key: Use a lock on the door and other physical means.

---

IBM VM/CSE:

DACLs: Yes
MAC: Yes

Now how secure can IBM's VM/CSE OS be? IBM structured people to come to work at five minute intervals. Why so nit-picky? Your brief-case or back-pack had to be inspected going both in and out of the building. You get to your office and now you have to login. Forget the one password and as many login attempts as you need. Do NOT open your briefcase or backpack. Lean it against your chair and type your user name (and yes, they have file ownership flags) and then your THREE passwords (a DACL setting).

If you foul up on any of those three passwords pick up your briefcase or backpack and head toward the guard scanning station leading to the door out IMMEDIATELY. If you don't you will be escorted there for the search and then out of the building by armed guards. You cannot attempt to login again until the next day and any attempt to minimize the wait time or login again will be seen by the VM/CSE OS as an attack which could lock out that user for a week. Most IBM main-frames are not that tight but the ones used by banks and finance institutions aren't much looser.

---

Unix (inclues all BSD systems & Unicos):

DACLs: No (can add on RSBAC if desired)
MAC: Yes

It all started to play a game. Most DEC PDP systems ran RT-11. That is just a run time OS. I don't remember RT-11 as having either DACL or MAC. A key to the door would get you in. But the guys that invented Unix did have infrequent access to IBM main-frames. The MAC is in the kernel itself and is thus not user configurable. For example, you cannot just get rid of Other access if you want to. All you can do is set the world flags to zero, thus denying all access. Changing the mode of files may look like a DACL, but it isn't. It is just modifying the parameters of a MAC ojbect. They implememted the MAC system to the UGO one that I gave you and forgot about DACL because they felt it was not needed (Unix was originally a one user system):

http://securemecca.com/public/ChmodTable.txt

It worked fine until the mmodern age of SQL servers, webservers, and more secure SMTP servers. I had more problems with sendmail than anything else. I gladly welcomed both Bernstein's qmail and Wietse Venema's Postfix (was VMail).

Still, something like RSBAC (SE-Linux is really only for Linux) CAN provide a lot of security for web servers and SQL servers:

http

Why is rsbac never mentioned on slashdot? It is, in my opinion, a better technology. At the least, it is a different approach, and worth mentioning. I use it daily, find it easier to administer than selinux, it is more portable, and does not need LSM. Check it out at http://www.rsbac.org/

I think RSBAC (linux kernel patch) covers that, and much more. http://www.rsbac.org/

Modularity brings flexibility but also introduces new attack vectors. It is quite possible that one of these vectors undermines the whole effort to secure the system because an attacker only needs one succesfull exploit while the "defender" would need to avert and disable every possible attack route.

There are various issues with LSM but one concern is that its symbols are exported. Thus, every rootkit and backdoor writer will will be able to use these hooks.

That is pretty much on target. SELinux only provides really only provides MAC (Mandatory Access Control). This is a big first piece but isn't enough to completely secure a system, there are still other considerations, such as system auditing, needed to have a fully trusted system.

For the most part SELinux provides binary compatibility for user space applications and ever since it was integrated into the 2.6 kernel provides binary compatibility with most modules... there are some modules that don't behave well with SELinux, some can be fixed with fine grained SELinux policies the rest need patches to their source to interact with the kernel correctly.

Applications don't really have anything to do with SELinux really, what SELinux (or really, what any MAC system does) is compartmentalize the system so that if any given application is compromised the break is limited to that one application and can not be capitalized on to compromise the system at large. SELinux and all other MAC systems rely on correctness of the policy configuration to provide system level security. Extra steps are still needed to protect each independent app though to make sure it is hardened against break-in. While it is important that a cracker is not able to take control of your box you still want to keep him from crashing your application server or web pages and such.

In addition to SELinux (NSA SELinux there are other MAC systems such as:
GrSecurity and RSBAC (RSBAC seems to be down though).

Other very interesting thing to look at are hardened tool chains (gcc with PIE, position independent execution and SSP, stack smashing protection) as well as PaX which is a kernel patch that provides extended security options such as ALSR (Address space layout randomization), non-executable memory. PaX provides some very strong kernel level features that harden all applications from attack. It does come at a slight cost though; some of the features have a minor performance hit, notably nx memory on x86 machines because they do not provide a true NX bit for pages, it has a fairly steep learning curve and some applications plain don't work with it... XOrg and Java VMs for example, because the way they are written they need executable pages for dynamic code generation. PaX security options can be set at a per file or per role (in a MAC system) level so it is still possible to run these apps, they just will not make use of the protection provided by PaX and will need to be tightened down in other ways. The really big gotcha with PaX is that elfloader doesn't support global offset tables or procedure linkage tables. These are required for ALSR in particular so to use PaX libraries need to be statically linked or loaded with dlopen... none of the current binary graphics card drivers for NVidia or ATI work with PaX so if you can't get 3D acceleration from DRI et al. you don't get 3D acceleration.

it has rsbac :)
http://www.rsbac.org/

http://pax.grsecurity.net/
Protection Against eXecution.

and integrate it with something decent like http://www.rsbac.org/

>>There's really nothing innovative today that Linux does that we can't do.

>Actually, I agree with his sentiment. He's bang on. There's nothing Linux does that Windows can't do, certaintly if you're willing to invest the time and effort to produce a solution.


It's not a sentiment, it's a falsehood ;) There are many things (innovative things, even) that Linux can do which Windows cannot, my favorite example being RSBAC, which provides a security extension framework under Linux that gives the administrator a fine-grained control over permissions that is quite simply not possible under Windows.

Ok... when are you going to fix the nearly 2-year old Linux Security Module (LSM)'s security vulnerability for inserting malicious kernel modules (aka virus or trojans)?

So, I'm thinking that these "sky-is-falling" guys that have been ranting, raving and waving red flags over at GRSecurity, RSBAC are starting to have a solid valid point on the inherent weakness of the LSM model.

I truly hope this is not the beginning of open season for Linux-virus/trojans.

Ah? Hmmmmm? Welll?

There are others too.

Here's a basic roundup of useful links:

• GRsecurity
• CIS Scan
• Openwall Project
• Bastille
• RSBAC
• SELinux

RSBAC should perhaps be considered. It is far more modular, been in production use a lot longer, has none of the disadvantages of selinux(eg works with any filesystem, needs no patches to filesystems, doesnt break other kernels on the same machone). It has a list of protections, has official PaX and virus(malware) scanner support, and the developer is always willing to take ideas from people and quickly fix issues. I would be interested for a detailed comparison of the two between slashdotters, thoughts and experiences etc.. But from everything I can see, RSBAC seems far superior. RSBAC.org

• UML
• ipsec
• ebtables & bridge-netfilter
• robert love's preemptable patch
• LSM-hooks (which make not everybody happy:grsecurity, RSBAC
• LS-module SE-linux
• filesystem-encryption
• apci 2.5 backports
• Kernel .config
• DVB-support

They must have beaten up Linus to get all those accepted ...

/graf0z.

How the hell is this insightful!? It's FUD!

Windows XP has USB 2.0

Wow, what an innovation... they have drivers for USB 2.0 devices. Wow... So do we.

it has low-latency audio

Let's see, does Linux...? Yep, we got that too.

it can play DVDs

Wow, do you think other platforms could do that? Yes, I think so.

it has translucent windows

Well actually, it doesn't. However, these guys have had it for a while and these guys are pretty close.

built-in NAT

Linux has had this since version 2.0. It worked great even back in 1999.

drag-and-drop CD recording

OKay, I'll conceed on this point, but I'll definitely mention you could find this here before Microsoft ever had a clue. As for XP drag and drop CD recording... it still doesn't work right.

an MPEG-4 media player

Once again, I reference these guys again. What's so impressive about that? Microsoft aren't even the people who introduced it.

it has an encrypted, compressed file system

Well, let's see here... yes, we definite have that too. As a matter of fact, I've been using encrypted file systems in Linux for years. As far as I recall, I was doing that before Windows was. No wait, Windows still doesn't offer encryption beneath the file system. Weak.

they have fine-grained access controls

Only very recently. Linux has enjoyed ACL from here and here as well.

they have a common language runtime

Funny thing is it was implemented by the open source community faster than Microsoft did.

They are pushing and developing modern programming languages so that we aren't all stuck programming in C.

A language is a tool Some languages are good for some tasks, some are better for others. For example, you couldn't quite write an operating system in Lisp like you could with C. To make this point shows how much of a fool you are. By the way, GCC compiles langauges other than C too.

Some of this technology sucks, and most of it they didn't invent, but they are pushing new technology.

Yes, most of it does suck but none of it is new. Microsoft only pushes regurgitations of what the rest of the industry has had (often for years).

(I also know that most of this stuff is available on linux, but it's also kind of a pain in the ass.)

I don't see any problems. None of what you mentioned was hard to find nor is any of it any harder to use than in Windows. For example, I play a DVD by loading my DVD player and press the button with the little triangle on it (play).

Your "points" fall down to absolutely nothing. Microsoft offers no advantages, just disadvantages over open source technologies.

You sir are a major corporate whore, completely deceived, clueless, not too bright, and giving free marketing hype to a multibillion dollar company. How does that make you feel?

Ok, so suppose there is a working DRM implementation in the kernel. I work as a sysadmin, providing desktop services on unix systems. Something like this would be great! I could sign all binaries that I trust to run with root privileges, and as long as my private key is safe, running unknown binaries as root becomes impossible. This will make root exploits somewhat more difficult, and if the BIOS supports it too, hacking the system with boot floppies/netboot etc. will be really hard. Think about it.

I can't believe somebody modded you up for that. This doesn't even begin to approach the level of security that the likes of Trusted Solaris and high end IBM software is at.

Well, I think it's better to see someone starting to walk that path, rather that just sitting there complaining that Linux doesn't even begin to approach the level of security of some other OS.

It's just a collection of security fixes and patches. It's not even introduction of an ACL system like TrustedBSD [trustedbsd.org] has. It's just a half-assed attempt at a security audit to remove the existing bugs.

From what I saw, after a cursory look at their page, they are using the RSBAC patch, which allows for quite a lot of security models (it is even extensible, like PAM on steroids, it seems). ACLs are just one of the supported models. The capabilities and resource models look quite useful, and I am very interested in learning more about their "functional control", "privacy" and "role compatibility" models. Also note the "malware scan" model, which scans for viruses and the likes on execution. Also, they state that models can be combined, and, furthermore, it seems that this can be applied to network accesses, not just files, which sounds like something I really, really want.

(Read the list of models with brief descriptions at their overview page.)

Note that I'm not familiar with this software (yet), so I can't say if it really is as good as it seems. But it looks very interesting --and a far cry from a "half-assed attempt at a security audit". I intend to try it as soon as I can.

> Isn't Trusted Solaris basically just this? At an OS level, you associate trust levels that permeate throughout your network.

I think this kind of approach is better than creating virtual machine sandboxes that still run the old weak UNIX security model. If someone 0wns your sandboxed apache, they can still likely cause
a DoS with it, or propogate worms, or pretty much anything really.

Good use of iptables and linux "capabilities" can help a lot with limiting what an application can do, but still don't go far enough, IMHO.

Look at projects like SELinux, LIDS, RSBAC, LOMAC
for examples of "free software" alternate security models.

And yeah, they're a pain for development, but then so is trying to program securely :)

- MugginsM

But this sort of thing is brilliant for companies, as it cuts down on the damage a employee can do on their PC.

It also restricts what data a sour employee can walk out of your company with.

Citing from their page: Key features:

• Open Source (GPL) Linux kernel security extension
• Independent of governments and big companies
• Several well-known and new security models, e.g. MAC, ACL and RC
• Control over individual user and program network accesses
• Any combination of models possible
• Easily extensible: write your own model for runtime registration
• Support for current kernels
• Stable for production use

Yesterday, as we all know, Microsoft fed an 'exclusive' story about its new 'Palladium' DRM/PKI Trust Machine to Newsweek hack Steven Levy (a guy who writes without irony of "high-level encryption"), presumably because they trusted him not to grasp the technology well enough to question it seriously. His un-critical announcement immediately sparked a flurry of articles considering what this means to the Windows user base.

And that's as it should be. But my question is, what does it mean to the Linux user base?

Well, of course no one knows yet; the Levy article is long on generalized promises but very short on details. We know that some hardware element will be involved -- some hardened slice of silicon on the mobo which will identify the computer and the user, and recognize other computers and their users. It, or a companion chip, will interface with some manner of PKI, current or future, so that only 'authorized' applications may run with privileges. MS wants us to think that the 'authorizer' will be the user, but we know better: there will undoubtedly be a DRM element in it, and its authorizations will override yours. There will also be a networking component, involving an elaborate PKI and vast data warehouses run by MS and its trusted partners.

So let's say Intel and AMD begin shipping Palladium-compliant boards as MS begins shipping the software to OEMs and shops. And let's say that the Redmond spin campaign, persuading users that this is actually for their benefit, takes hold, and consumer demand for the scheme begins to grow and it eventually becomes a de facto standard, like SSL today, for example.

Got root?
All right then, how do we get Linux and open-source servers and apps to work with networks using this master scheme? What changes will be necessary?

The first thing that comes to mind is the difficulty of getting my Apache Web server to work seamlessly with Harry Homeowner's Windoze box when he comes to my site for some eminently trustworthy business. Everything I download to him (and this may even include Web pages -- the scheme is that far-reaching) will have some manner of digital cert which MS and its family of cronies will have established beforehand. I don't see a problem here. The certs will be embedded in the content and I'm merely providing space for it to reside. Even pages and images can be digitally signed and Harry's box can simply accept them or not according to rules he's worked out for himself.

But what if Harry needs to transact business and/or send me something? Then I think it gets tricky for two reasons. First, I have to be able to assure him that I can't read what he sends (and neither can the script kiddies who root my site monthly), and second, I'll probably have to pass part of it along 'safely' (as defined by MS) to some other network under Redmond suzerainty where the bulk of Harry's whole life's data is stored and continually updated. And of course I'll need access to that data so I can be sure Harry is Harry and his Mark of the Beast (or whatever MS will call his Uniform Identifier) is valid.

So to validate Harry, and to update his Master Data File -- two bits of business integral to the Palladium scheme -- I'll need hardware, an OS and a server compliant with Redmond specs. Now MS says they're going to make the sources to the core of this technology open. But considering Microsoft's white-knuckled terror of Linux and open source products in general, combined with its established penchant for mining its products with hidden little pissers for the competition, I don't think it's paranoid to imagine that I may have to turn to a packaged product from a major MS partner/collaborator or a Linux distributor who's gone to the bother of obtaining certs for the kernel and the apps. But either way we'll have major GPL problems, as we'll see below. Indeed, this is going to be something of a reductio ad absurdum.

This certification scheme will rip the guts out of the GPL. That is, the minute I begin tinkering with my software, my ability to interface with the Great PKI in the Sky will be broken. I'll have a Linux box with a GPL, all right; but if I exercise the license in any meaningful way I'll render my system 'unauthorized for Palladium' and lose business. So instead, I imagine I'll be turning to my vendor for support, updates, modifications and patches. And I'll be dependent on them for support services at whatever price they can wheedle out of me because I dare not lose my Palladium authorization. I wonder if the cost of ownership of an open-source system will actually be lower than the cost of a proprietary system under such circumstances.

If MS can't wipe out Linux, at least they can throw their marketing might and obscene quantities of cash into the project of castrating and controlling it by rendering the commons hostile to Linux users who still have their balls. They can in a sense create a huge market for open/closed hybrids, just as I imagined above: a system that comes with a GPL which I dare not exercise, and with considerable costs of both purchase and ownership. Even Dell might get into the castrated Linux act when they see what sort of stranglehold the Palladium scheme will enable them to place on it.

But here's the diabolical bit. Linux distributors are going to lose big time if they remain faithful to the GPL. Palladium will either break the GPL, or if not, break Linux.

Harry's lament
I fully expect to see Linux on the desktop growing rapidly in the next several years. The major distros like SuSE and Mandrake are coming along nicely with classic Harry features like automatic updates. Hardware detection is getting better by the day. Open Office is rapidly approaching the point where it imports from and exports to MS office without difficulty. The 2.4.x kernel is finally showing signs of the 2.2.x's legendary stability. The KDE desktop is looking sharp and working nicely now with version 3.0. Mozilla is coming along wonderfully. And now Red Hat says it intends to commit seriously to the desktop market.

As the obstacles to Windows migration fall away, inherent virtues like better security and privacy (your Linux box does not automatically connect to servers at Microsoft whenever you search your hard disk, for example), freedom to configure, redemption from the MS update crack-addiction, and low cost of ownership will strike more chords with the computing public.

This terrifies MS as much as the enterprise Lintel phenomenon. And it's not just cost rationale at play here. There's a revelation in store for users once they have something to compare their Windows eXPerience against. As home users come to use and understand Linux, they'll automatically begin to perceive what a parasite Microsoft really is.

The answer to this will be more parasitism: Palladium is a means of infesting the commons with hostile digital fauna. As these new services and applications become more plentiful, the need for the Linux desktop to deal with them according to Redmond spec will increase as well.

Kernel hackers will have their hands full figuring that one out. How do you make Linux interface with a security chip in such a way that untrusted applications are sandboxed without taking root away from the machine's owner? I think the answer is, 'you can't,' and I imagine Redmond thinks so too. And what will Palladium mean to application development? More overhead, that's what. Certification authorities charge for their services. Some applications in development may have to be scrapped due to the costs of certification.

Eventually, as Palladium contagion spreads, the home Linux box will need certified open-source apps to run DR-managed content. Here goes the GPL again. So I've got this certified app. Fine. I've got the sources. Fine. What happens if I decide to build my own binaries? They won't be certified. They won't work. So what does the GPL mean to me then? It means I can build, or modify and build, an application which will lack the digital cert which it needs in order to run the content it was designed to run. Only the binaries will be certified (as a moment's reflection will make obvious). This is a nail in the GPL's coffin. Yes, I can improve the app and give away or maybe even sell my improved version; but first I have to prove that it qualifies for certification, and second I have to pay for the cert. And when I release it, source and all, only the certified binary will function.

The entire concept of root will be out the window. If I build my own or re-compile my existing kernel, my certs won't work. I won't be permitted to log in to the Microsoft Digital Empire or any of its numerous colonies because that little chip on my mobo is going to freak out. Perhaps even my certified apps will fail to run. And I can no longer present my Uniform Identifier at the digital immigration turnstiles which MS will be setting up as I meander through cyberspace. "Sorry, we don't know who you are; you'll have to turn back...."

So how is this going to work in practical terms? Will the Linux distributors release certified kernels and apps and utilities? I don't see how they can avoid it. But what happens to the GPL in that case? Will the certification authorities decline to certify the distro if the kernel and app sources are included? Or will the machine simply lose its Palladium authorization and fail to work properly if apps or the kernel are re-compiled or built from external sources?

Either way, the GPL is perverted. Any GPL'd kernel, utility, application, whatever, that's designed to be Palladium compliant will have to be distributed without certified sources. There's simply no way to ensure that a source archive can only be used to build compliant binaries, unless GCC is deliberately broken in some radical way and the security hardware won't allow other compilers to run (except similarly broken ones).

Will there be a hybrid Linux/hardware package coming out to address this? A sort of black box -- a mere desktop appliance not unlike an X-Box or a Palladium-enabled Windoze box -- with no compiler, and only user privileges, and some hardware chip that prevents modifications to any of the binaries except by digitally-signed RPMs pre-approved for Palladium compliance? That means basically that MS has got root on my machine, and of course it would rip the guts out of the GPL to boot. [Reader Stephen Crane points out that Rule Set Based Access Control (RSBAC) might well suit such a product, which would then make MS not root but the 'Security Officer' of my Linux machine.]

It's the very fact that this appears insoluble to me that helps me realize that MS has put tremendous, careful thought into it. To make the commons Linux-hostile, MS is taking dramatic steps to make it GPL-hostile. Very clever and admirably diabolical.

Of course here I'm assuming Palladium won't become the next Microsoft Bob. It could meet with severe consumer rejection, as I hope it will. And so we end with a question for lawyers, not for me: is a technically-valid, letter-of-the-law GPL which you can't practically exercise violated or not? You've got your sources and everything in the distro is GPL'd -- only any binaries you choose to build on your own will isolate you from the commons. I think MS believes it's found a loophole here. Whether it will work or not is another question.

In any case, it's time for Tuxers to take the gloves off.

The Rule Set Based Access Control ( RSBAC ) system is an open source security extension to current Linux kernels, which has been continuously developed for several years. The current stable version 1.1.2 has been released on 27th of August 2001.

RSBAC was designed according to the Generalized Framework for Access Control (GFAC) to overcome the deficiencies of access control in standard Linux systems, and to make a flexible combination of security models as well as proper access logging possible.

Access control is devided into enforcement, decision and data structures, and all access modes are grouped into abstract request types. Also, the controlled object types include interprocess communication as well as devices (not only device special files).

The abstraction makes the framework and the existing model implementations easily portable to other operation systems.

Among the nine access control models, which are currently included, are well known ones, like MAC/Bell-LaPadula, as well as new models, which have been specially designed for *nix server needs. Specially, the complex and powerful Role Compatibility model and the Access Control Lists model provide fine grained control over all objects in the system, while the Authorization model easily controls user IDs used by all programs.

Installation requires a kernel patch, RSBAC configuration and a recompile. The complete set of administration tools contains a range of menues for most tasks.

Practical experience shows the system to be fast and stable for production use, what is one reason for its growing acceptance. There are already two Linux distributions with RSBAC included and a lot of server systems running it.

In the next major release 1.2.0, real network access control will be provided and the whole access control data handling subsystem will have been changed and optimized.

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.

There is the very cool Rule-Set Based Access Control System, which allows you to erect any access control model you can think of (and write a module for, if it's really custom).