Date: Wed, 15 Apr 1998 21:41:56 -0700 (PDT) From: dima@best.net (Dima Ruban) To: louie@TransSys.COM (Louis A. Mamakos) Cc: dima@best.net, tsprad@set.spradley.tmi.net, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Message-ID: <199804160441.VAA03293@burka.rdy.com> In-Reply-To: <199804160426.AAA06207@whizzo.TransSys.COM> from "Louis A. Mamakos" at "Apr 16, 98 00:26:55 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Louis A. Mamakos writes: > > Louis A. Mamakos writes: > > > > > > > One more time. In some cases you don't want your users to read kernel > > > > namelist. Generic kernel source code won't help. > > > > > > So, chmod 440 /kernel on *your* system. > > > > > > And how many cases are there where other programs installed on the system > > > need to read the kernel namelist? You'll break those by making a change > > > in the distribution. > > > > Every program that needs to have an access to the kernel namelist needs to > > be sgid to kmem (if it's not already sgid to root). Otherwise it won't be > > able to do _anything_ with this information. > > > > Which means - this change is not going to break anything. > > By this reasoning, there's no point in removing read permission either. Of course there is. Because user doesn't need to have this information. > Perhaps I'm looking at the symbols debugging a problem? Or because You must be kidding. You don't have a root access on some machine and you're looking for the kernel debugging information on it??? > I'm curious how the kernel was configured, so I do a > > strings /kernel | egrep '^__' > > to get the file fed to config(8) and embedded in the file? Ask sysadmin. > > > > Another example. Do search on your local box for all the programs, that > > > > don't allow 'others' to read the binary. Ever wonder why? > > > > > > Hmm.. I found exactly 1 - suidperl. This is hardly a compelling argument > > > to change a well established convention. > > > > What about suidperl? > > Yeah, what about it? A more likely example would have been a program > with some password embedded within it. We don't see to have any of > those. Ahh, that's what you've meant. I thought, you were saying that 0440 permissions on kernel will break suidperl. > > > I don't dispute the utility to some for changing the permissions on the > > > /kernel file, but it's just not clear this is a universally good idea. > > > Next thing you know, you'll want to chmod 440 /etc/rc.conf :-) > > > > Changing permissions on rc.conf won't do _any_ good. > > And removing read permission from the kernel does? > > This all seems like FUD. You seem to have unspecified reasons why > you don't want your users to look at the symbols on your kernel. I > suggest you remove read permission on your machine. It seems that the > potential downside of removing read permission is greater than the > unspecified gain of doing so. There's no potential downside. Or you can call having a root password a potential downside, because qurious user won't be able to see your configuration. > > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804160441.VAA03293>