[report] (24-03) Ubuntu Hardened work tracking

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Lorenzo Hernández García-Hierro wrote:
> Hi,
> 

Hey :)

> The following issues are reported to the Bugzilla and being worked on,
> finished or re-worked:
> 
[..]

> #2: Hardened Debian patches for GCC 3.3 and 3.4 (security related
> enhancements)
> https://bugzilla.ubuntu.com/show_bug.cgi?id=4374
> 
> Currently, gcc-3.4 sources come with the patches, they are not enabled
> nor used in the binary packages.
> After studying the case, after looking at an alternative gcc-ssp package
> (which would lead to unnecessary maintenance overhead and conflicts), we
> have decided that having SSP/ProPolice enabled in the default toolchain
> is the way to go, but not making it *functionally* enabled, which means,
> users would need to explicitly set the needed flags (-fstack-protector*,
> PIE related flags...).
> 
> New libssp packages are being made available, also, the kernel patch for
> kernel-level helpers might be submitted for inclusion:
> 
> http://pearls.tuxedo-es.org/patches/propolice_1.2-2.6.11-rc5.patch
> 

Awesome.  So is this Hoary being gcc without SSP at all, Hoary+1 being
gcc with SSP and SSP used with packages; or is Hoary going to be GCC+SSP
to allow a testing ground to set up for Hoary+1 GCC+SSP+SSP_BASE in 5.11?

> #3: PT_PAX_FLAGS marking support on binutils.
> https://bugzilla.ubuntu.com/show_bug.cgi?id=4380
> 
> As of the on-going effort for deploying PaX, made among the proper
> Ubuntu Hardened team, by Martin Pitt, fine-grained marking for
> executables is needed in order to provide softmode support, etc.
> 
> The impact of the inclusion of the PT_PAX_FLAGS marking support into the
> toolchain, more concretely into binutils, has been known to *don't* be
> negative, among the little overhead of having another dpatch to maintain
> or check.
> 

Yeah.  Kernel won't bother looking at PT_PAX_FLAGS, it'll just shrug.

Ubuntu may be able to make a patch to the kernel for upstream, just to
be nice, to make the -rR flags (random mmap(), stack, heap) disable the
kernel's default ASLR (PaX removes this and replaces it with its own
anyway; but the vanilla kernel relies on PT_GNU_STACK for both "do I
need an executable stack" and "is stack/mmap randomization on?").  If
you want to be nice anyway; I don't much care but hey, I might as well
suggest it just to nudge everyone towards convergence.

The idea is that PT_PAX_FLAGS is very robust, controlling 1) NX
(PROT_EXEC) enforcement; 2) all randomization except (3); 3) ET_EXEC VMA
mirroring hack for non-pic randomization (very evil, just leave this off
on everything); 4) enhanced memory protection restrictions (bring the
protection model into the control of the kerne); 5) Trampoline emulation
to avoid disabling (1) in some cases.

(1) overlaps the basic function of PT_GNU_STACK; and (2) overlaps any
type of control of the new (very light) vanilla kernel randomization,
which currently PT_GNU_STACK controls as well (bad hack).  By equating
the uses between vanilla, exec shield, and PaX/GrSecurity kernels,
distributors could simultaneously support all of these configurations.
Of course, until Exec Shield got EMUTRAMP ported from PaX, (5) would
have to be treated as (1) or PT_GNU_STACK on ES as well; but that's for
Ingo Molnar to deal with.

So yeah, Ubuntu can go ahead and write that stuff up, or not care, as I
don't and thus am not going to bother racking my brain pretending I know
what I'm doing with it.

[...]
> 
> #5: enh: Ubuntu Security Center
> https://bugzilla.ubuntu.com/show_bug.cgi?id=7825
> 
> John Richard Moser proposed a worthy enhancement to the user's final
> experience, which should be subject of study and further looking, as
> it's deployment could help more than just the Ubuntu Linux users, being
> a key tool for desktop users and making user-friendly the deployment of
> the security technologies at issue.
> 

Yes, I think this would be awesome, of course.  Basically, Bastille plus
control of the nice enhancements the Hardened herds have been working on
for years, which Hardened Ubuntu is bringing to Ubuntu.  The PaX, SSP,
and GrSecurity stuff would all go nicely to Gentoo (Hardened Gentoo) and
Adamantix, as well as anyone else who ever deployed this stuff; so it
could indeed fully aid many outside of just the Ubuntu community even
with those specific options.  Things from Bastille would of course be
about as universal as Bastille is :)

> #6: Consider setting more restrictive default ulimits
> https://bugzilla.ubuntu.com/show_bug.cgi?id=8170
> 
> We all know on the later noise coming from an (maybe sensationalist, at
> least more than needed ...) article published on SecurityFocus
> (http://www.securityfocus.com/columnists/308), fork bombs being subject
> of discussion, when a simple ":(){ :|:;}:" can make people blaming at
> even the kernel security...
> 

Yes, this is an issue for servers where multi-user log-ins occur.  It's
a local DoS.

For your home PC, nobody should really care.  It's a bunch of line noise
that's mostly if not completely overboard on a simple desktop, even a
business desktop; nevertheless, this is an issue, as someone, somewhere,
may be running Ubuntu as an enterprise grade server; is this not
Cannonical's eventual business goal, as they are (to my knowledge) not a
non-profit organization?

In short, fix this.

> Anyways, enforcement of process execution, memory, priority and open
> file descriptors limits should be studied and subject of further look in
> order to ensure that such issues don't fill our bug tracking /SCM
> archives.
> 
> At this point, profiles-based solutions come to mind, so, we could talk
> on a desktop, server and normal profile, each one of them could make use
> of the different security technologies and configurations, depending on
> the needs of the user, sysadmin or fooman at issue :)
> 

Security center, individual user groups, anyone in "servers" has free
reign, normal "users" have to stop at 2048 processes.  By default,
desktops have no memory limit for users; servers uhhhhhhhhh :)  I'm not
an enterprise server solutions engineer.

"Users and Groups" and the "Security Center" go hand in hand.  Obviously
there are security operations you want to do per-user or per-group.  It
may be possible to have the "Security Center" integrate the "Users and
Groups" UI by having the "Users and Groups" stuff go into a library to
let its dialogs snap into any other program.

 Then again, it would have to look "slightly different" in the "Security
Center," so you'd be maintaining something massively complex, or two
codebases.  Perhaps "Users, Groups, and Security" would be a better idea.

> --
> 
> And that's all folks (at least for this month).
> 
> Regarding the SELinux deployment, we need to discuss a few things:
> 
> 	* dpkg changes: we can't rely on postinst rules, we should look
> 			for better solutions before falling in the 
> 			current one.
> 	* policy:	provide separate policy packages for each binary
> 			package (foo and selinux-policy-foo), improve
> 			the current package (the configuration method
> 			is weird :( )...
> 	* user-land:	fill bug reports for the bugzilla (or malone if
> 			it changes) on each package which should be
> 			modified for SELinux support and get Fedora's
> 			patches from their repositories.
> 	* kernel:	fabbione, keep up the good work ;D
> 
> Cheers,
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCRK/4hDd4aOud5P8RArvgAJ9PSEoX/IIhU/arjVG3iuazEA2MJgCfVNxG
MkFkSXjFLukWWNjV2phbIr8=
=iExK
-----END PGP SIGNATURE-----