Dailydave mailing list archives
Re: Media Excitement!
From: pageexec () freemail hu
Date: Tue, 10 May 2005 01:28:17 +0100
the policy comes from the ELF header or an ACL system, enforcement is in the VM, all separate.Well ok, another point was that if i had to mark elf headers, or sysctl things then my policy overlaps to some degree, because i have to allow things to be written to in my selinux policy, and if chpax can write to the X server for example, to change things and i have dri enabled, then that would cause a nasty problem of anyone being able to run chpax would have a path to kernel memory, ugly. the point is is that i prefer the separation to be in one place.
i think i lost you somewhere here. on one hand you're using selinux+pax and even know about Joshua's ACL hook and on the other hand you're complaining that you have to make exceptions in your policy for chpax. that looks like a contradiction to me ;-). the PaX ACL hook exists for the explicit purpose of not having to touch the files, if you're not using it, then it's a problem with your particular deployment, not PaX.
Where are the tools that allow me to make assertions about SSP + grsecurity ... thats the point.
not sure how SSP has anything to do with enforcement/policy, but let me answer for grsecurity: there's much less (if any) need for such tools, that's the point! first, you're assuming the second meaning of 'policy', that is, it's something that describes a 'grand scheme' and then of course you want to know to what extent it succeeded. grsecurity's 'policy' is of the first meaning, that is, it codifies (and enforces) existing behaviour. in plain english, what you express in the policy (typically after learning and manual adjustments) is already what you want, you don't ask yourself the question whether you got it or not because by definition you did. if you want to use grsecurity for enforcing policies of the second kind then you may or may not be able to do so (much like selinux of course, as it can't express everything either), it all depends on what kind of granularity is needed to express your policy. second, grsecurity policies are human readable and hence comprehensible, compared to selinux, so grep (and some shell scripting at most) will answer most of your questions. third, if selinux is actually the super system people make it out to be, then its capabilities must be a superset of that of grsecurity, hence one can just write a tool to convert grsecurity policies to selinux and use the selinux tools on them - problem solved, albeit probably not the way you expected it ;-).
you dont need to run the tools to create a policy. If i want to see all the indirect domain interactions (by that i mean if this program can spawn this program that can do this and eventually read this file) creating paths from one domain to a target context i can do so. If i cannot easily make assertions with grsec + SSP then my point stands, regardless of how silly it sounds.
how's 'grep' sound for 'easily'? you grep your per-subject policy files and get the answer in no time, can hardly be simpler, can it. and now you're saying that selinux needs a special tool for just that and wondering why it sounds silly...
Obviously creating policy auto-magically is not something i think is a good idea, a good example is if xlock wants to read shadow, and my `learning mode' allows it to do so, xlock can now reach shadow. i can assert this and change so its not the case, and in fact, xlock will happily function without reading shadow, creating a .xlockrc file instead.
i think you have the same misconception about the learning mode of grsecurity as many other selinux advocates. learning mode is not about creating all the policy for you, it's about creating a good enough 'first approximation' about what your system actually does. then you (the human) go through it and modify it as you see fit - not unlike you do with selinux, is it. so your example above applies to grsecurity as much as it does to any other system, in either case you spot the problem yourself or by a tool (which for grsecurity would be a simple 'grep', on selinux you apparently need something more complex, not something to be particularly proud of).
The problem it turns out is admins who know nothing about selinux, just want it to go away, i cant argue with that, the fact that they want to do all sorts of silly things without learning selinux is not something i can easily fix. Perhaps someone else can come up with a solution for that i dont know, I think people are even trying to do this, by abstracting the policy, but i think this leads to gaping holes, but its a trade off with granularity and ease of use if someone is not willing to learn the policy i think.
the solution is to stop trying to shove down people's throats a complex system they don't need when less complex systems can do just as good (if not better) a job. complexity is the enemy of security. _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com https://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Re: Media Excitement!, (continued)
- Re: Media Excitement! pageexec (Apr 22)
- Re: Media Excitement! robert (Apr 22)
- Re: Media Excitement! pageexec (Apr 22)
- Re: Media Excitement! Cody Hatch (Apr 24)
- Re: Media Excitement! robert (Apr 24)
- Re: Media Excitement! Cody Hatch (Apr 25)
- Re: Media Excitement! Jack (Apr 25)
- Re: Media Excitement! Cody Hatch (Apr 26)
- Re: Media Excitement! pageexec (Apr 26)
- Re: Media Excitement! Jack (Apr 27)
- Re: Media Excitement! pageexec (May 09)
- Re: Media Excitement! robert (May 09)
- Laptop Abuse halvar (Apr 25)
- Re: Media Excitement! robert (Apr 24)
- Re: Media Excitement! pageexec (Apr 26)
- Re: Media Excitement! robert (Apr 26)
- Re: Media Excitement! pageexec (Apr 26)
- Re: Media Excitement! byte_jump (Apr 26)
- Re: Media Excitement! robert (Apr 26)
- Re: Media Excitement! Anton A. Chuvakin (Apr 21)
- RE: Media Excitement! Ben Nagy (Apr 21)