Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Apr 1998 10:13:30 +0200
From:      Philippe Regnauld <regnauld@deepo.prosa.dk>
To:        dima@best.net
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: kernel permissions
Message-ID:  <19980416101330.18307@deepo.prosa.dk>
In-Reply-To: <199804160511.WAA03453@burka.rdy.com>; from Dima Ruban on Wed, Apr 15, 1998 at 10:11:28PM -0700
References:  <E0yPgmY-0004v7-00@set.spradley.tmi.net> <199804160511.WAA03453@burka.rdy.com>

next in thread | previous in thread | raw e-mail | index | archive | help
	[Cc: trimmed to a politically correct size]

Dima Ruban writes:

	[...]

> Okay. Here's an example. Ever hear of a commertially available drivers?
> When you install such stuff, you don't want somebody to be able to read
> them, or have a copy of kernel with them. Why? Because you did pay for them
> and whoever wants to have an access - didnt.

	Commercially available drivers are shiiped in object format.
	There's very little chance it's exploitable straight out of the 
	kernel -- nothing like the sources to said driver.

> Normal users *do not need* to have an read acces to the kernel.
> They simply don't.

	I just remember the same discussion, oh about two years
	ago, and IIRC, the general idea (from core) was that
	it was unnecessary to remove read/exec bits on a file
	without a strong motivation -- the reason being,
	as mentioned earlier, that "we were not your average
	commercial UNIX entity" and didn't share the "Pentagon"
	approach. 

	BUT, things may have changed in the meantime:

	1) The Jerk/Hacker ratio has unfortunately increased these
	   last years
	2) FreeBSD is increasingly known as an ISP platform
	   ("reliability, security, efficiency", pick _three_) --

	   Thus, removing the read bits on the kernel MIGHT make
	   sense for the out-of-the-box configuration that
	   Mr.ISP will be using, if for some God-obscure reason
	   he wishes to have shell accounts on his machine.

	   Then again, we are (hopefully) all grown up enough
	   to make our own security policy, _including_ writing
	   shell scripts that once-and-for-all do the appropriate
	   changes on *our* system.

	   <CHEAP STAB>
	   I also remember an argument being, "Ah, we don't want to
	   start doing like the Linux people who set everything they
	   can to 440"
	   </CHEAP STAB>

	:-)

> Do you need any other examples?

	Yes:

	Preventing things in the eventual (unproven) fear that
	they could be exploited in some way (not necessarily
	security) is, IMHO, "change for the sake of change".

	If you can prove me wrong regarding the "commercially available"
	driver mentioned above, I'll shut up :-)

> What's the deal with arguing on such a simply issue?

	Oh, BSD conservatism, cast-in-stone code, superstition
	and old grumpy hackers ?

-- 
 -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]-
     «Pluto placed his bad dog at the entrance of Hades to keep the dead
	    IN and the living  OUT!  The archetypical corporate firewall?»
                      - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib)

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980416101330.18307>