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

[Geoff Kassel]

> > 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.
>
> We could have something similar to SELinux here. I mean: a policy
> structure in directories, which could be used to generate the final policy
> file. That would keep the effort in userland.

This is pretty much what I meant, yes :)

> Udev-event based mechanism for eg.

The idea of udev-style notification mechanism works for me.

> RSBAC have console type graphical UI for config editing.
> I really like the idea of having a separate security officer in RSBAC as
> well as the separate authentication system for grsecurity. It's a second
> line defense mechanism makes it harder to bypass. But it also makes harder
> to an everyday user to easily tamper with the security policy. I think
> this second line should be kept.

Ah, I'd forgotten about this - it's been a while since I've dallied with 
RSBAC. I agree - the security officer is a good idea for systems where 
everything runs by default as root. I see it as another tactic in the whole 
privilege separation strategy of trying to maintain process security. 

I've forgotten why I'd abandoned RSBAC - perhaps it was the difficulty in 
getting a fully functional system running. (Maybe that's changed since I last 
tried it. I remember admiring the set-based ideas behind it - maybe I should 
give it another shot sometime.) 

I know I settled on the Hardened sources because it was easier to selectively 
turn on or off security systems where they interfered with processes I wanted 
to run - which brings me back to my rant about easily managed security 
systems. If you can't selectively disable parts of the system without a 
reboot or kernel recompile, it's going to be 'all too hard' for many users.

On Thu, 14 Feb 2008, atoth@××××××××××.hu wrote:
> On Sze, Február 13, 2008 13:08, Geoff Kassel wrote:
> > 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?
>
> Chris PeBenito is the person who probably have the most detailed knowledge
> of SELinux here. I think it's more complex to develop a policy for an
> application using SELinux, but a well designed framework provides
> guidance. Targeted mode offers a chance to create a balance between
> security and usability giving the chance for the everyday user to make use
> of the technique without having to spend time on the policy or facing with
> failing applications.
>
> >> 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.
>
> We could have something similar to SELinux here. I mean: a policy
> structure in directories, which could be used to generate the final policy
> file. That would keep the effort in userland.
>
> >> 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
>
> Udev-event based mechanism for eg.
>
> > 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
>
> RSBAC have console type graphical UI for config editing.
> I really like the idea of having a separate security officer in RSBAC as
> well as the separate authentication system for grsecurity. It's a second
> line defense mechanism makes it harder to bypass. But it also makes harder
> to an everyday user to easily tamper with the security policy. I think
> this second line should be kept.
>
> < snip >
>
> > 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.
>
> That's way to much for me for now...
>
> 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