Re: [gentoo-hardened] Keeping gentoo-hardened alive

[Geoff Kassel]

> It would be a good strategy IMHO to recruit graduates to work on security
> stuff. It's a really fascinating topic to immerse in the depth of the
> toolchain and its security features - for a passionate graduate. Of course
> it requires a supervisor...

Any PhD supervisors in computer science academia on the list? I dropped out of 
my PhD due to illness and haven't gone back, so I can't supervise any PhD 
students in this area, unfortunately.

> I think grsec would need some kind of configuration mechanism similar to
> SELinux. It could be either implemented on a per-ebuild basis or as a base
> policy.

I like the idea of the SELinux per-application policies. I've never used them 
or SELinux, though, so I don't know how effective or simple they are to use 
IRL. Anyone else care to comment on this?

> That could be further extended with additional features according
> to the particular box. Using m4 would be a good candidate to generate the
> redundant per user stuff.

Oh yes, this is the most tedious part of the grsec configuration. A good UI 
tool of some kind would help gloss over this. (If we're still talking 
hypothetical features here.)

> I think many of us could contribute to the
> policy. The hardest task would be to agree on the differences regarding
> the security requirements. But that could be made configurable also.
> Configuration intelligence could investigate the contents of the conf
> directory to tailor the policy to the specific settings...

Hmm... configuration-wise, I'm envisioning a directory tree under /etc/grsec 
with per-user and per-application branches (because detailed grsec policy 
files get very big very quickly), so that differences or changes in 
requirements can be managed easily via comparing differences between flat 
files.

You could then provide different sample configurations at install time based 
on different common security requirements, and make it easy for either manual 
or (G)UI configuration of the grsec security system.

Applying policies post-install then becomes a matter of inserting new 
configuration files under the appropriate per-application and per-user 
directories. Conflicts with existing files are then managed by the system 
administrator running etc-update.

> I have to regularly revise my policy to keep the box running. I've also
> ended up loosening the security in order to make the system usable.

As much maligned as Vista's UAC system is, I feel there's one positive thing 
about it - it's handy to have a mechanism to notify the user about potential 
security violations or issues in real time, to avoid usability problems like 
this from preventing basic system function. It's best if it can be done in a 
way that notifications can be hidden, filtered, and managed by the 
user/administrator in an adaptive way that avoids the 'just click allow' 
mentality, which is where I feel the Vista UAC gets it wrong. (And ends up 
causing just as many security problems as it's supposed to solve.)

How about a user-configurable UI (something that could be run on a bare TTY, 
like, say, tty11, or on any other command line, for that matter) for the 
management system - secured from physical intrusion by sudo-style logins for 
each management decision, if desired - with applicable X/Gnome/KDE/your 
favourite WM clients for real-time notifications and configuration? 

(Someone please tell me if I'm reinventing the wheel here, and SELinux has had 
this for years.)

> I think it depends on the type of denial. If it's a textrel, that's not so
> serious. However if it's a stack-smashing: I don't want to have a single
> piece of those code on my system...

Agreed. So expanding on your ideas, with a hypothetical adaptive access 
control management system, textrels could automatically be filtered out 
without notification. (Although if it's a GUI application with textrels, and 
a suitably integrated window manager is running, I'd like to see a tiny icon 
like Konqueror's Javascript bug icon appear to shame the program author into 
tidying up their code.)

Stack smashing attacks should continue to automatically trigger an immediate 
termination of the process and a core dump like they do now - but could also 
do additional things like quarantine the parent executable so that it can't 
be easily run again by the user. (Like what good anti-malware software does 
on Windows.)

Evasive procedures would have to be controlled and managed centrally by an 
administrator, of course, as the whole system could be compromised if the 
wrong decision is made by a user. But everything else could end up in a file 
stored for each user - say in ~/.grsec - which would be referenced by any 
(G)UI access control management clients.

Sound reasonable?

Okay, enough daydreaming for me now :)

Regards,

Geoff Kassel.

On Wed, 13 Feb 2008, atoth@××××××××××.hu wrote:
> On Sze, Február 13, 2008 06:07, Geoff Kassel wrote:
> > No problems. My background in QA is primarily regression testing and code
> > quality reviews (although it's been ages since I've done any of this with
> > C) - my formal methods background is formal specification, model
> > checking, theorem proving, and formal derivation of code from formal
> > specification. (Yes, I'm a recovering academic :)
>
> It would be a good strategy IMHO to recruit graduates to work on security
> stuff. It's a really fascinating topic to immerse in the depth of the
> toolchain and its security features - for a passionate graduate. Of course
> it requires a supervisor...
>
> > While I'm dreaming I'd also like to do something about making GRSEC
> > easier to
> > set up (an upstream issue, I know) as it has so much promise, and the
>
> I think grsec would need some kind of configuration mechanism similar to
> SELinux. It could be either implemented on a per-ebuild basis or as a base
> policy. That could be further extended with additional features according
> to the particular box. Using m4 would be a good candidate to generate the
> redundant per user stuff. I think many of us could contribute to the
> policy. The hardest task would be to agree on the differences regarding
> the security requirements. But that could be made configurable also.
> Configuration intelligence could investigate the contents of the conf
> directory to tailor the policy to the specific settings...
>
> > basic
> > configuration isn't nearly as paranoid as I'd like it to be :) and it's
> > very
> > difficult and time-consuming to make it so. I gave up doing so, and I
> > like to
> > think I'm not a complete n00b. PaX, PIE and SSP are practically
> > fire-and-forget in comparison.
>
> I have to regularly revise my policy to keep the box running. I've also
> ended up loosening the security in order to make the system usable.
>
> > Speaking of PaX, another great, impossible thing would be to have a
> > kernel-level feature for handling PaX violations in a less violent manner
> > (core dumps are violent, in my mind) - perhaps suspension of the process
> > in
> > question until investigated, with the possibility of resumption or
> > termination by someone with sufficient security permissions. (Perhaps I'm
> > just unaware of an already existing feature.) Again, an upstream issue.
>
> I think it depends on the type of denial. If it's a textrel, that's not so
> serious. However if it's a stack-smashing: I don't want to have a single
> piece of those code on my system...
>
> Regards,
> Dw.
> --
> dr Tóth Attila, Radiológus Szakorvos jelölt, 06-20-825-8057,
> 06-30-5962-962 Attila Toth MD, Radiologist in Training, [phone],
> [phone]
-- 
gentoo-hardened@l.g.o mailing list