linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heusden, Folkert van" <f.v.heusden@ftr.nl>
To: sean@dev.sportingbet.com
Cc: Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: random PID generation
Date: Tue, 27 Feb 2001 11:35:57 +0100	[thread overview]
Message-ID: <27525795B28BD311B28D00500481B7601F0F1D@ftrs1.intranet.ftr.nl> (raw)

> I have already written a 2.2 implementation which does not suffer from
these 
> problems.

Yes, someone pointed me at it. To be honest (and with all due respect): I
found
it to be a bit over-complicated. Like; in my opinion it's only usefull to
have
absolute random chosen PIDs, or not. Not all those options are needed in my
opinion.

> It was rejected because Alan Cox (and others) felt it only provided 
> security through obscurity. 

Yeah, well, yeah. My patch wasn't actually ment to be included in the main-
kernel. I agree with the security-by-obscurity argument altough I think it's
_not ALWAYS_ a bad thing.
What I am trying to say is: I agree that sofware should be written so that
they can't be exploited in one way or another. But since software is written
by humans, it's likely that bugs stay always in. Furthermore; it's always
possible that in the future new exploits are invented which exploit things
the original programmer didn't think of, and also; new libcs might have
security-problems which affect your software. To prevent that your system
gets cracked by some script-kiddie, I found it a good thing to patch the
mainstream-kernel with patches that disable executable stacks, make the
/proc filesystem more restricted, etc. etc. And in my quest for creating a
secure-as-possible system which anticipates on future exploits I found that
using random PIDs is a good thing.
I hope I made myself clear; english is not my native language which makes
this a rather big chalenge.


Greetings,
Folkert van Heusden
[ www.vanheusden.com ]

             reply	other threads:[~2001-02-27 10:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-27 10:35 Heusden, Folkert van [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-02-23 15:34 random PID generation Heusden, Folkert van
2001-02-23 15:40 ` Matt Johnston
2001-02-23 17:14   ` Sean Hunter
2001-02-23 17:50     ` Richard B. Johnson
2001-02-23 13:20 Heusden, Folkert van
2001-02-23 14:18 ` bert hubert
2001-02-22 15:35 Heusden, Folkert van
2001-02-22 22:24 ` bert hubert
2001-02-22 21:42   ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27525795B28BD311B28D00500481B7601F0F1D@ftrs1.intranet.ftr.nl \
    --to=f.v.heusden@ftr.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sean@dev.sportingbet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).