Alternatives to gr security for shell service?

[PaX Team]

SELinux also contains an equivalent of PaX' PAGEEXEC|MPROTECT,
so I think the comparison is fair enough.

no, it doesn't. they haven't even considered PaX style HIPS techniques important until, well, PaX ideals and techniques became widely known and accepted (not that they have ever credited anyone but themselves about it, mind you). simple proof: enable the SELinux memory protection restrictions on a i386/non-PAE vanilla/SELinux kernel and see what you get. still equivalent to PaX? SELinux is about access control, not low-level memory protection schemes.

and speaking of no kernel bugs in SELinux, care you enlighten
the folks at securityfocus that the following apparently doesn't exist: http://www.securityfocus.com/bid/17830,

1. That bug was discovered by SELinux developer *before* somebody actually hit it.

ok, so you're now changing the topic from 'kernel bugs' to 'kernel bugs not discovered by the author'. fair enough, here's the next one then that supposedly doesn't exist, according to you:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6056

2. There's a CVE and detailed analysis of the bug (see http://marc.info/?l=selinux&m=114226465106131&w=2)

i don't know when exactly it was discovered by Stephen Smalley, but it was fixed about 2 years (!) too late. have you got evidence that noone else had discovered it in that time?

[Alexei.Sheplyakov]

we're talking about security bugs, not bugs in general.

Any Oops triggered by user is a DoS, hence it's a security bug.

in my judgement it wasn't a security bug but feel free
to prove me wrong.

You claim it can't be exploited => It's you who have to prove this claim.

it was a test patch, not a release so no changelog.

It does not matter, because the "release" (which contains several security
bugs BTW) is not supported anyway.

besides, due to the way 2.6 is developed and we can track it,
we're surely not going to announce every silly bug we come across

<sarcasm>
Now I know what "innovative approach to security" stands for.
</sarcasm>

FYI, i think a good chunk of PaX, possibly up to one half of it,
is now such bugfix/feature reversal/rework/cleanup/etc.

I'm afraid that chunks gives rise to more serious problems than it's
supposed to solve.

[Alexei.Sheplyakov]

simple proof: enable the SELinux memory protection restrictions on
a i386/non-PAE vanilla/SELinux kernel and see what you get.
still equivalent to PaX?

<sarcasm>
No. Those wonderful Oopses due to SEGMEXEC bugs are definitely missing.
</sarcasm>

SELinux is about access control, not low-level memory protection schemes.

Access control is pointless without proper memory protection, so SELinux
implements some memory protection too. To some extent they are even better
than PaX (i.e. fewer bugs).

ok, so you're now changing the topic from 'kernel bugs' to 'kernel bugs not
discovered by the author'.

No, I was speaking about 'bugs which byte almost anyone' as opposed to
'some obscure theoretical' ones.

here's the next one then that supposedly doesn't exist, according to you:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6056

1. This bug has very little to do with SELinux. It's a bug of the HFS
filesystem driver (i.e. hfs_fill_super returned success even if it
failed to find the root inode).
2. The bugfix was announced properly (i.e. there is CVE and it's mentioned
in the ChangeLog/commit message, see e.g. http://lwn.net/Articles/218515)
3. Last, but not least, the attacker is already privileged user.

i don't know when exactly it was discovered by Stephen Smalley, but it was
fixed about 2 years (!) too late.

The "stable release" of grsecurity has (at least) two unfixed bugs (related
to vma mirroring). One of them was discovered almost year ago. Anyone cares
to fix it?

have you got evidence that noone else had discovered it in that time?

No.

[PaX Team]

we're talking about security bugs, not bugs in general.

Any Oops triggered by user is a DoS

not all oopses are DoS, it requires a case-by-case analysis to determine the impact of the oops.

You claim it can't be exploited => It's you who have to prove this claim.

You claim it can be exploited => It's you who have to prove this claim. mind you, this is a kindergarten style argument, but if you want to get this silly, so be it .

It does not matter, because the "release" (which contains several security bugs BTW) is not supported anyway.

all correct. your point being?

<sarcasm>Now I know what "innovative approach to security" stands for.</sarcasm>

no, you apparently don't know. what you do seem to know is how to make unsubstantiated claims then fail to take them back when proven wrong.

I'm afraid that chunks gives rise to more serious problems than it's supposed to solve.

what makes you say that? do you even know what chunks i was talking about? have you got any reports to share that any of them introduces a bug?

[PaX Team]

<sarcasm>No. Those wonderful Oopses due to SEGMEXEC bugs are definitely missing.</sarcasm>

ok, i guess i can take it as an admission that you were wrong about comparing PaX to SELinux.

Access control is pointless without proper memory protection

no kidding. we've pioneered it in grsec.

so SELinux implements some memory protection too.

for the 2nd time, SELinux does not implement ANY memory protection. what does implement them is the kernel's VM subsystem, and it does so to varying degrees per architecture. what SELinux adds to this is the extension of access control to make use of the memory protection capabilities.

To some extent they are even better than PaX (i.e. fewer bugs).

oh, and here you almost made me believe that SELinux was bugfree. i have to disappoint you though because the SELinux memory protection controls are not better than PaX, in fact, they very pointlessly split the privilege of runtime code generation into a set of privileges per 'major memory areas' (heap/stack/textrels). that's called cargo cult security but hey, if you like it better, feel free to use it.

No, I was speaking about 'bugs which byte almost anyone' as opposed to 'some obscure theoretical' ones.

no you weren't. here's what you said, word by word:

At least, SELinux does not introduce new kernel bugs.

tell me where that says 'which byte almost anyone'. right, it doesn't. but since you insist on this game, here's the next non-existent does-not-bite-anyone SELinux bug:http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=219f0817038cabc722968e914490adf6b686499e. and this one cannot possibly bite anyone either: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b20c8122a3204496fca8b5343c93b60fe11dad04. i'm sure you'll have a perfectly good explanation why they're not exploitable bugs. that would also explain why i couldn't find CVEs for them, correct?

1. This bug has very little to do with SELinux.

except it doesn't manifest without SELinux? why don't you tell that to MITRE then? in any case, you've got two more genuine SELinux non-bugs above .

The "stable release" of grsecurity has (at least) two unfixed bugs (related to vma mirroring). One of them was discovered almost year ago. Anyone cares to fix it?

vma mirroring was rewritten for 2.6.22, so any previous bugs are no longer relevant (read: we won't fix them in that kernel version) and i think i have one outstanding one on the new code, still waiting for feedback.

have you got evidence that noone else had discovered it in that time?

No.

in other words you've just contradicted yourself then here:

1. That bug was discovered by SELinux developer *before* somebody actually hit it.

[Alexei.Sheplyakov]

not all oopses are DoS, it requires a case-by-case analysis
to determine the impact of the oops.

Most of them are. Especially if the machine freezes after an Oops.

You claim it can be exploited => It's you who have to prove this claim.

I see, "the innovative approach to security". However, in the old fashioned
one every Oops is assumed to be exploitable by default, unless someone
proves otherwise.

mind you, this is a kindergarten style argument,

Absolutely not, it's a pessimistic estimate.

It does not matter, because the "release" (which contains several security
bugs BTW) is not supported anyway.

all correct. your point being?

You don't care a s**t about long standing bugs in your code and still
bash SELinux for not fixing a (minor) bug in a timely manner, and claim
some obscure filesystem bug to be SELinux one. What a nice ++doublethink.

[PaX Team]

not all oopses are DoS, it requires a case-by-case analysis to determine the impact of the oops.

Most of them are.

i see you're changing from 'any oops' to 'most of them'. in that case, do you have statistics to back up your claim? let me guess, you don't.

You claim it can be exploited => It's you who have to prove this claim.

I see, "the innovative approach to security".

what's that got to do with responding to your baseless bashing? let me quote you myself, the part you apparently didn't get:

in my judgement it wasn't a security bug but feel free to prove me wrong.

do you understand what 'in my judgement' means? in case you don't, so let me explain it for you: it means, Alexei, despite whatever you might believe, that i actually looked at the bug/code in question, analyzed its impact as best as i could and then i determined it was not a security bug. now if you still insist it is a security bug (and i certainly could have made an error in my judgement), then the onus is on you to prove it. incidentally, that's what i told you already, in your own style but apparently you're only quick to accuse others, not so quick when it comes to backing up your claims, let alone admitting your mistakes.

However, in the old fashioned one every Oops is assumed to be exploitable by default, unless someone proves otherwise.

noone was talking about that, let alone questioning it. see above.

You don't care a s**t about long standing bugs in your code and still bash SELinux for not fixing a (minor) bug in a timely manner, and claim some obscure filesystem bug to be SELinux one. What a nice ++doublethink.

woohoo, that was a mouthful, wasn't it . so let's see. what long standing bugs do i not care about? (provide URLs). note that bugs in non-supported versions don't count because they don't count for SELinux either (or any kernel subsystem for that matter). say, any outstanding bugs in 2.6.19 are not going to be fixed by kernel devs there, so you can't hold a similar stance against us either, i hope you agree. and the reason we track only one version (vs. 2 or 3 as done by the kernel dev community/companies) was explained already (lack of resources), so you can't hold that against us either, right?

second, where did i bash SELinux for "not fixing a (minor) bug in a timely manner"? i merely pointed out that your claim that SELinux didn't have exploitable bugs was flat out wrong, nothing more. and as i told you at least twice by now, that "obscure filesytem bug" was not attributed to SELinux by me, it was done by MITRE. go complain to them, not me. and remember, you still have the two SELinux bugs to explain. or admit you were wrong.

as for doublethink, you probably meant something like double measure instead or i can't parse it (what would be the two contradictory ideas i believe in?). in either case, feel free to elaborate on it.