[sentinix-list] Re: [QUESTION] Updates?

I took the liberty to CC this to the mailing list...

On Thursday 04 March 2004 21:35, you wrote:
> Michel --
>
> What is the project team going to do about updates to all of the packages
> within the distribution?

Nothing?  Just kidding ;)
There's no package management in 0.70.5, as you know. Next version is the 
first version with full package management. It'll be binary packages that can 
be installed, removed and upgraded (as one would expect).

I recently got stuck on how to authenticate the packages. Now I've reached the 
conclusion to sign every package with my GnuPG key, and ship my public GnuPG 
key with sentinix.   Of course, then no one will be able to make packages for 
Sentinix, except me... unless modifying sxpkg (the package manager).  Package 
authentication is *obligatory* IMHO!

>  Since you were kind enough to point out the
> recent 'ploit that was announced today off the French K-OTIK web site, this
> raises an issue about maintainability of the distribution.  If you are
> going to have a distribution, you have to take into account that there will
> be TFI's out there that will want you to constantly and continuously "hand
> hold" for them.  I ask this only because someone has *already* brought up
> this issue.

Yes, that's the main pain-in-the-butt for distro vendors as I see it.  I'll 
tell them this...  I rather put time and effort into making Sentinix immune 
to buffer overflow attacks than keeping to-the-minute updated packages.  If 
someone is more interested in "getting the latest shit", then they don't want 
Sentinix.  If someone wants a distro that's immune to exploitation, they'd 
like Sentinix.

How will Sentinix be immune to exploits?  If Hiroaki Etoh's patch for gcc 
works (it's based on StackGuard by Immunix)... then *all* stack-based buffer 
overflow attempts will be void.  The "plain" and "smp" kernels will be 
replaced with grsecurity kernels, PaX will double the barrier against 
stack-based and heap buffer overflows.  As for the "om" and "omsmp" kernels, 
Hiroaki's stack protector will keep the overflows at bay, so if one wants to 
run an openMosix cluster, they can feel *nearly* as protected as running the 
grsecurity kernels.

As for other kinds of vulnerabilities, like "input validation errors", these 
will all be addressed separately and *hopefully* eliminated as time goes by. 
This sounds like "push into the future", but it's far from it!

Most other distro vendors (to avoid mentioning any names) have failed to keep 
any kind of *decent* security... just look at http://zone-h.org  specifically  
http://www.zone-h.org/en/stats ...
Now, which OS tops the chart?  It says Linux, indiscriminately.  What it 
really should say is Red Hat, SuSE, Mandrake, Slackware, etc... oops.. there 
I mentioned those names... darn! ;)
Their approach on dealing with vulnerabilities is:
Don't think about security -> patch -> distribute patch -> loop.

Linux has had *several* nasty bugs... just a couple of days ago a new exploit 
for a *new* mremap vulnerability (do_munmap) was publicly disclosed. It 
didn't work on Sentinix' 2.4.21 kernels, but I tested it on 2.4.22 and it 
roots it in sub-second time.  I don't want to take the approach that these 
vulnerabilities are "minor" issues, they aren't...
If one takes them seriously, *especially* the "new" "e-sport" called 
"defacement", one would want to take some time and try to understand what the 
root of the problem is...

Sentinix 0.70.5 isn't really much better... it's basically vanilla... no 
services are protected against future, undiscovered vulnerabilities. So far, 
the only goal for Sentinix has been to get it done and working... but since 
it does that now, I need to take it to the next level, which is to secure it!

In reality, no system is safe if it's on the Internet, that's *law*... but 
let's *at least* try and break those laws... ;)

If anyone is interested in helping out to create some security enhancing 
features for Sentinix *and* the community at large... let me know, 
*especially* if you code C and have experience with hacking the kernel...
I have several ideas!!

>
> Perhaps a CVS site for updates for the minor/security fixes or releases,
> and FTP for major fixes or releases?  Just an idea...

The devel is in CVS nowadays... The "source tree" is designed (or are being 
designed) to allow me to create binary packages *fast*, those will then be 
available through rsync and ftp, so anyone who wish to keep all packages on 
their box could do so, and automatically upgrade packages too, if that's what 
they wish.

	Michel