grsec vs rsbac

[ether]

Hello. I was curious if anyone could offer a compare&contrast type of thing regarding grsecurity versus rsbac? I have used grsec for a few months now and am pleased with it (although my old acls don't seem to work in the newest version). I saw an email on bugtraq mentioning rsbac which I have never heard of but it looks like it may be similar. Could anyone shed some light on what the main differences are? Thanks.

[spender]

RSBAC offers many security models, though I'm not sure in real application if people really need all of them. For everything I do, grsecurity can do what I want. If it couldn't, I wouldn't be using it. RSBAC also is much slower than grsecurity, on the order of 40x slower. RSBAC administration I have also found to be much more difficult (their menu-based configuration didn't make it any easier). You could spend weeks trying to configure it, and you would still have no idea whether the configuration you made was secure. Grsecurity enforces things to ensure that you don't make fatal mistakes that could make any security you thought you added to the system worthless. I believe grsecurity is a better choice, not only for these reasons, but because grsecurity also offers many more things than just an ACL system, but things like the chroot protections and PaX, which are of real benefit.

-Brad

[ether]

Thank you for your reply. My company is definitely staying with grsecurity.

[spender]

Just some fun facts on performance. RSBAC with nothing enabled adds the same performance hit as grsecurity does with everything enabled, no matter how many ACLs you have (this includes all the PaX features, and all other features of grsecurity).

-Brad

[magicq]

rsbac is too difficult to configure,but if grsecurity add one jail function,it may be better,I ported from freebsd , i like the jail() very much in freebsd,I really hope grsecurity have the jail() one day

I thought many freebsd fans using linux need it

[pbusser]

How nice, to speak of competing products without providing any verifyable facts... Let me provide a few facts here in order to keep some balance in this discussion.

RSBAC provides an improved FreeBSD-like jail function, for those who like the BSD jail stuff. RSBAC provides much more than that.

Basically RSBAC consists of two parts. A framework and a set of modules. The framework is the plumbing behind all the security features found in RSBAC. It hooks into the kernel and makes sure that every module is consulted whenever something important happens in the system. This sounds like LSM, and that is correct. But LSM was primarily designed for performance, RSBAC was primarily designed for security.

As such it is not strange that using RSBAC costs performance, although not as much as Brad likes to think (I would like to know how Brad measured the difference). When I boot my development box, I do not notice a difference in performance between the PaX only kernel and the PaX+RSBAC kernel.

Since the framework guarantees that every module is consulted, the number of modules enabled in the kernel configuration clearly influences the overhead. When you enable all modules, which is possible, but rather pointless, it will take more performance than when you enable only one module. The RSBAC site lists some (outdated) figures (efficiency has improved since then). None of them seem to indicate a 40x speed difference though.

RSBAC is actually not overly difficult. I would say that it is not more difficult than learning UNIX. But it takes time to get used to it, just like it takes time to get used to UNIX. RSBAC is a security toolbox with which you can easilly combine security features. Like UNIX it is extensible, you can write your own security modules that can be loaded at runtime. And they will be treated like any other RSBAC module. Like UNIX and unlike gr-security, it does not force you to use a predefined security policy. I would like to compare gr-security with the MS-DOS command line and RSBAC with the UNIX command line.

When people say that they can do the same with gr-security as with RSBAC, then they are only comparing the simple things, just like you can list directories in both the MS-DOS and UNIX command lines. The real power of the UNIX command line is the ability to combine things. And that is also the power of RSBAC.

There will be a number of modules that support a learning mode in the next RSBAC version. And for Adamantix I wrote a tool which uses text files for loading the security policy. So improvements are made to make RSBAC more usable. It is much harder to make something like gr-security more flexible and powerful though, because you have to change the architecture. Something which RSBAC got right from the start.

Basically it boils down to what you want. If you need raw performance, than use no security patches, each and everyone of them will cost performance.

If your security requirements are low and you do not want to learn anything, then gr-security might be good for you.

If your security requirements are high and diverse, and you are willing to spend some time learning about security, then RSBAC might be good for you.

One final note: There is one Linux distribution which provides RSBAC support out of the box, it is called Adamantix (http://www.adamantix.org). And Adamantix and RSBAC are free software projects, but also developed and supported by people who are being payed by companies to do this, which guarantees the long-term viability of these projects.

[spender]

As such it is not strange that using RSBAC costs performance, although not as much as Brad likes to think (I would like to know how Brad measured the difference). When I boot my development box, I do not notice a difference in performance between the PaX only kernel and the PaX+RSBAC kernel.

I took the performance data from the RSBAC website. It's simply a fact that grsecurity with any number of rules, using all features of grsecurity, is faster than RSBAC with NOTHING enabled on it. I have published my performance results.

RSBAC is actually not overly difficult. I would say that it is not more difficult than learning UNIX. But it takes time to get used to it, just like it takes time to get used to UNIX. RSBAC is a security toolbox with which you can easilly combine security features. Like UNIX it is extensible, you can write your own security modules that can be loaded at runtime. And they will be treated like any other RSBAC module. Like UNIX and unlike gr-security, it does not force you to use a predefined security policy. I would like to compare gr-security with the MS-DOS command line and RSBAC with the UNIX command line.

I would say that it is more difficult than learning UNIX. I've used RSBAC before. 99% of users don't want to write their own security modules. Think back to the days of DOS. Who was using DOS, and who was using UNIX? Do you think mom and pop would be using UNIX? I'll take your analogy and say that the same applies to RSBAC. If you're building a fence to keep dogs out, is it necessary to build a 100ft wall with notches at the top for easy access to add more height to the wall? The dogs are only a few feet tall. What's the point of all the extra bloat? As much as you'd like to believe it, bigger is not always better. And when you tell someone they need a 100ft wall to keep out the dogs, they're going to ignore you and choose something that fits the purpose. I would say that grsecurity is popular because it takes a realistic approach to security. We know the problems, we know who the enemy is and what they're capable of now and what is possible in the future, and we have ideas on how to protect against that. As far as I'm concerned, every other project is so removed from the real problem that they try to overcompensate for their lack of understanding by throwing in a bunch of unneccessary code.

There will be a number of modules that support a learning mode in the next RSBAC version. And for Adamantix I wrote a tool which uses text files for loading the security policy. So improvements are made to make RSBAC more usable. It is much harder to make something like gr-security more flexible and powerful though, because you have to change the architecture. Something which RSBAC got right from the start.

This shows a lack of understanding of grsecurity. As an analogy, if you build a house and I tell you it's not a very good bicycle, my statement would be silly. You neglect to take into account the goals of the project. Grsecurity has a purpose and it serves that purpose. I would say there's great security benefit in a project that has a purpose as opposed to a project that allows the user to make any mistakes in policy that they want. Simply having a learning mode is not enough, as I'm sure you'll soon find out. The ability to log normally denied accesses is trivial. It's the analysis and reduction that is a very difficult problem. Grsecurity can create least privilege policies for the entire system with no configuration.

So I still don't see how RSBAC is better, and I also don't see how any of my facts are unverifiable. If a smart attacker owns X, SSH, or the kernel, the game is probably over in grsecurity (PaX will give them a hard time), but most definitely over in RSBAC and SELinux. What do you have to say about that? What in RSBAC stops someone owning SSH from running code inside it that sniffs all text sent over the server? What prevents someone who owns X from modifying the kernel through /dev/mem, as X requires that access? What in RSBAC stops someone from launching a kernel exploit against munmap? These are problems that can't be solved by some bloated framework for different formal security models. A more intelligent solution is needed, and grsecurity (and PaX) are the only projects working towards that goal. If people ask for a problem to be solved, they're not asking for you to throw them a toolbox and tell them to do it themselves. In what other industry is this an acceptable answer? I won't accept that answer, and anyone that wants security to progress further won't accept that either.

[pbusser]

Hi!

Quote:

I took the performance data from the RSBAC website. It's simply a fact that grsecurity with any number of rules, using all features of grsecurity, is faster than RSBAC with NOTHING enabled on it. I have published my performance results.

Right, those numbers are outdated. Efficiency has improved since then. You still do not explain which number you took from the web site and how you compare it to gr-security.

Quote:

RSBAC is actually not overly difficult. I would say that it is not more difficult than learning UNIX. But it takes time to get used to it, just like it takes time to get used to UNIX. RSBAC is a security toolbox with which you can easilly combine security features. Like UNIX it is extensible, you can write your own security modules that can be loaded at runtime. And they will be treated like any other RSBAC module. Like UNIX and unlike gr-security, it does not force you to use a predefined security policy. I would like to compare gr-security with the MS-DOS command line and RSBAC with the UNIX command line.

99% of users don't want to write their own security modules.

Fortunately not, that would be a waste of time. My point is that you can extend RSBAC in any way that is necessary, without having to alter the architecture. It makes experimenting with new security features possible. For instance, the PaX support in RSBAC was first implemented as a loadable module. In the upcoming v1.2.3 release, it will be an integral part of RSBAC.

Think back to the days of DOS. Who was using DOS, and who was using UNIX? Do you think mom and pop would be using UNIX? I'll take your analogy and say that the same applies to RSBAC.

The number of UNIX users is growing, and so is the number of RSBAC users.

If you're building a fence to keep dogs out, is it necessary to build a 100ft wall with notches at the top for easy access to add more height to the wall? The dogs are only a few feet tall. What's the point of all the extra bloat?

What you call ``bloat'' is actually necessary functionality. While you had to rewrite lots of gr-security to accomodate RBAC, no such thing was ever necessary for RSBAC. Because it got the architecture right from the beginning.

As much as you'd like to believe it, bigger is not always better. And when you tell someone they need a 100ft wall to keep out the dogs, they're going to ignore you and choose something that fits the purpose.

You are talking about the biggest fence. I am talking about flexibility and therefore choice. For example, if you have low security needs, then you could use RSBAC to manage Linux kernel capabilities, resources and setuid. That is all standard Linux security stuff. You don't need to learn any formal models to use it like that.

If that is not sufficient, you can add ACLs (similar to Novell ACL stuff, which many people already know). Or the more advanced models if you want.

The nice thing is that the setuid management module and the ACL module have a learning mode in the upcoming v1.2.3. So you don't have to specify everything in menus or from the command line.

I would say that grsecurity is popular because it takes a realistic approach to security.

I think that gr-security is popular because many people do not know much about security. And therefore take anything that is more secure than the bare Linux kernel. Even if it is something like gr-security.

As an analogy, if you build a house and I tell you it's not a very good bicycle, my statement would be silly.

It wouldn't be the first time you said something silly.

Simply having a learning mode is not enough, as I'm sure you'll soon find out.

Thank you for stating the obvious.

The ability to log normally denied accesses is trivial. It's the analysis and reduction that is a very difficult problem. Grsecurity can create least privilege policies for the entire system with no configuration.

Well, I can also claim that my bycicle will never suffer from motor damage. I mean, there is only hard-coded policy and a simple ACL model in gr-security. There is hardly anything to configure. Not that there is much flexibility and security there either.

So I still don't see how RSBAC is better, and I also don't see how any of my facts are unverifiable.

It is easier to see with your eyes open you know.

If a smart attacker owns X, SSH, or the kernel, the game is probably over in grsecurity (PaX will give them a hard time), but most definitely over in RSBAC and SELinux.

You're talking about PaX features here, not gr-security features. Your ACLs don't stop someone from owning X, OpenSSH or the kernel, it is PaX that does that. Adamantix has PaX in the kernel.

What do you have to say about that?

I'll tell you what I have to say about this: You make a lot of wild claims. But provide no proof whatsoever. Normally that is a sign that someone doesn't know what he's talking about.

These are problems that can't be solved by some bloated framework for different formal security models.

Basically you are now saying that the ACL and RBAC extensions in gr-security are worthless. You have a nice way of contradicting yourself.

I always recommend people to never depend their system security on one mechanism. That is why the Adamantix kernel has PaX *and* RSBAC. And that is why all binaries are compiled and linked for PaX Address Space Layout Randomisation (ASLR). And that is why GCC has been extended with the Stack Smashing Protector (SSP).

You may like to think that you invented the security in depth concept, but I can assure that that it existed long before you were born.

A more intelligent solution is needed, and grsecurity (and PaX) are the only projects working towards that goal.

Yeah, you are indeed working towards that goal. You still have a long way to go. RSBAC with PaX is already there.

If people ask for a problem to be solved, they're not asking for you to throw them a toolbox and tell them to do it themselves.

People tend to have different knowledge and different needs. Gr-security clearly targets the low-end. RSBAC can be used for both low-end and high-end stuff, but is probably more appealing for high-end stuff.

Groetjes,
Peter Busser.

[spender]

Right, those numbers are outdated. Efficiency has improved since then. You still do not explain which number you took from the web site and how you compare it to gr-security.

kernel compilation benchmarks: the same as RSBAC did. I've published my results. I've already told you this. It's not my fault that you can't read them.

The number of UNIX users is growing, and so is the number of RSBAC users.

That's the stupidest thing I've ever heard. *UNIX* users are NOT growing. Linux and other UNIX variants are growing in users because they're innovating; they're making things more user friendly; they're catering to the needs of the users. I see no parallels at all with RSBAC here.

The nice thing is that the setuid management module and the ACL module have a learning mode in the upcoming v1.2.3. So you don't have to specify everything in menus or from the command line.

Your learning mode simply can't compare to that of grsecurity, and it never will. I should call it something other than a learning mode so people won't think it's the same trivial learning mode as that of RSBAC.

Thank you for stating the obvious.

It must not be that obvious, as you're touting it (above) as the best thing since sliced bread, as if you're done with your usability work.

Well, I can also claim that my bycicle will never suffer from motor damage. I mean, there is only hard-coded policy and a simple ACL model in gr-security. There is hardly anything to configure. Not that there is much flexibility and security there either.

This is ridiculous. I'm not even going to argue with this filth. Read what you said and notice the inherent assumptions in it and flat out lies. It will probably be difficult because you don't understand anything about grsecurity. Get out of your cubicle for a while.

It is easier to see with your eyes open you know.

I would say the same to you. Your eyes are clouded by stupidity and not even knowing who you're trying to protect against.

You're talking about PaX features here, not gr-security features. Your ACLs don't stop someone from owning X, OpenSSH or the kernel, it is PaX that does that. Adamantix has PaX in the kernel.

grsecurity is NOT PaX + RBAC; grsecurity is grsecurity. PaX is part of its model. And BTW, we are working on ways to stop those kinds of exploits from succeeding. What are you doing about it?

I'll tell you what I have to say about this: You make a lot of wild claims. But provide no proof whatsoever. Normally that is a sign that someone doesn't know what he's talking about.

I would say the same about you.

Basically you are now saying that the ACL and RBAC extensions in gr-security are worthless. You have a nice way of contradicting yourself.

I always recommend people to never depend their system security on one mechanism. That is why the Adamantix kernel has PaX *and* RSBAC. And that is why all binaries are compiled and linked for PaX Address Space Layout Randomisation (ASLR). And that is why GCC has been extended with the Stack Smashing Protector (SSP).

You may like to think that you invented the security in depth concept, but I can assure that that it existed long before you were born.

No, I'm not, because as I just said, grsecurity is grsecurity. So you can't talk about individual components. They each have their purpose in the big picture. You don't seem to realize that. I don't care who is first with the "security in depth concept". Apparently you do.

Yeah, you are indeed working towards that goal. You still have a long way to go. RSBAC with PaX is already there.

That's the funniest thing I've ever heard. So you've achieved perfect usability and perfect security? That's amazing.

People tend to have different knowledge and different needs. Gr-security clearly targets the low-end. RSBAC can be used for both low-end and high-end stuff, but is probably more appealing for high-end stuff.

Again, you avoided my comment. RSBAC is not a security solution. It is a toolbox. People do not ask for toolboxes when they want a solution.

This is a forum for grsecurity support. This is not your personal space to advertise for Adamantix and how you're commercially funded. You clearly know nothing about grsecurity. Anyone that looks at the features page knows you're an idiot when you say there's nothing to configure if you want to. Any further stupid replies to this post won't be responded to. I don't have the time to waste on people that can't do a shred of research and claim to be security experts.

-Brad

[torne]

My experiences with Adamantix (I can't comment on RSBAC too much in general) were pretty bad; also, aside from technical differences (ease of configuration and use..etc) there seems to be vastly insufficient communication back to the Debian folks whose work is the basis for Adamantix. I agree with spender; it's providing a toolbox when most people want a solution.

My previous server used Debian with grsecurity; I used Adamantix for nearly a month on my test machine before giving it up in favour of grsecurity. My now-deployed replacement server runs Hardened Gentoo (which, like Adamantix, has full position-independent executables, stack smashing protection, IPSec support..etc, and *unlike* Adamantix allows you to make executables non-readable to prevent people from finding function offsets) with a grsec kernel, and am extremely happy with both my configuration and how easy it was to get set up (my old machine ran grsec 1.9 which was much less comfortable).

Applause to spender, and stern glances at people who make sweeping statements about their product's superiority on the tech support boards of their competitors.

[thomasko]

Brad & Peter, is there any good reason for insulting each other? When I saw this topic with posts from both of you, I thought I would be able to find here interesting discussion about pros and cons of both projects, so I would be able to compare it with what I know about both projects. But it turned to very impolite flamewar... ;(

Anyway, I have questions on both of you:

Peter, can you write more about this:

I think that gr-security is popular because many people do not know much about security. And therefore take anything that is more secure than the bare Linux kernel. Even if it is something like gr-security.

Why do you think "security-conscious user" would never choose grsecurity?

Brad, which features (according to you) could turn RSBAC from toolbox to usable solution?

Thanks in advance for you answers!

th.

[spender]

simple, human readable configuration
*advanced* learning mode
enforcement of a base policy
self-auditing

those are some of the things *necessary* for it to be a solution and not a toolbox. These things alone are not *sufficient* however.

One of the reasons grsecurity is so popular is it identifies common security problems and provides a method to protect against them with no runtime configuration, namely:

/proc restrictions
linking restrictions
chroot restrictions
etc

It also doesn't require any userspace modifications (of course the user is always able to add on more security by using things like propolice and the like). RSBAC's jail for instance requires source modification to use the new jail system call. That doesn't sound too user-friendly to me.

-Brad

[spender]

BTW Peter, can you make a public post here saying the RSBAC jail is unbreakable?

-Brad

[devastor]

It's very wrong to say that security-consious people would never choose grsecurity, because
it's simply not true.

grsecurity is a real security solution. It (with pax included) provides all the necessary key elements that are needed to make the system secure.

Yet you don't have to be any security genious or kernel hacker to be able to use it and still get real security instead of just false sense of security. But even if you are a security genious it still has a lot to offer.

grsecurity team has proven to understand what they're up against and what is needed to stop the attacks. The development is of course going on.

If RSBAC team think they've already reached some goal then I can only be sorry for them.

When talking about security, arrogant attitude is very bad.

RSBAC is an alternative, and I'm sure it also has a lot to offer.

In my opinion grsecurity is just much more usable and more complete at the moment.

[pbusser]

Hi!

Brad, as you should know: Nothing is unbreakable. There are probably bugs in RSBAC, just like there are probably bugs in gr-security. You won't hear me claim that anything is unbreakable.

As to the fact that Adamantix sucks: Yes it sucks, because it has many shortcomings. The project is little over a year old now. And there is only a handful of developers working on Adamantix. Things are improving, but it takes time.

As far as the relation between Adamantix and Debian is concerned, that has been problematic since the Trusted Debian v1.0 announcement. But anyone who says that Adamantix doesn't communicate with Debian developers is not really well-imformed. There are a number of Debian developers working on Adamantix. And I've talked to a number of other Debian developers who don't. But I do not communicate with people who shout and yell and insult me. Perhaps some of you enjoy doing that, I don't. (Well, with the exception of talking to Brad, but then, it's fun to make Brad angry.)

MS-Windows became popular because it provided a solution for people who had a problem. The price people pay for the ``graphics for everything'' solution is that it makes the system less flexible. I know I would be extremely unhappy if I had to restrict myself to using a GUI only, even though it seems to make millions of people very happy. I.e. one size does not fit all.

Last time I used gr-security (granted, that was a few years ago), I had to change the kernel configuration and recompile the kernel everytime I wanted to change something in the configuration. It reminds me of the arbitrary limitations of MS-Windows.

With RSBAC, there are basically hardly any such hard-coded limitations. The JAIL module doesn't have to be perfect, because you can combine it with RC (Role Compatibility), ACLs and a number of other security modules. When Amon developed PaX support, it was first distributed as a separate module. In the next version it will be included in the standard RSBAC patch. The same goes for the new on-access virus scan module. I.e. you can add tools without having to redesign the box everytime you do that.

It is correct that RSBAC in itself is not a security solution. That is why there is work going on in Adamantix to use this RSBAC security toolbox for creating security solutions. And yeah, I know that there are still many problems with that. As I said: The project is still very young. It will improve in time.

Anyways, Brad is right, I'm stupid. Stupidity is a great excuse to learn new things. That is what I try to do everyday. The few things I learned, I can share with you. But if you want to talk to someone who has got all the answers, then you shouldn't talk to me.

Brad: Next time you have problems with getting RSBAC JAIL to work, join #rsbac or #adamantix, there are always people who are willing to try to help you out.