Re: Media Excitement!

[pageexec () freemail hu]

> > 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