[lug] dumpdates

[Chris Riddoch]

John Starkey <jstarkey at ajstarkey.com> writes:

> > You're safe with that option, but modules are not a bad thing, really.
> 
> Seems they'd slow the system down??

Not enough to be worth thinking about. When a module registers itself
with the kernel, it provides a structure of function interfaces to the
kernel, so they can talk to each other.  The thing is, this only
happens once when you load a module, and it's simply not much of an
issue.  It'd be a better use of time to help make smaller spinlocks in
the kernel so it can work more efficiently.  Spending your time
building a kernel without modules will probably be a waste of time,
because modules won't be slower unless you're constantly loading and
unloading them, and I don't imagine you actually sit around all day
and run modprobe in your spare time. ;)

> > Only root can load modules into the kernel.  I've heard of malicious
> > modules being loaded into kernel and disappearing from sight by
> > modifying the filesystem and module-handling code, but if someone has
> > root access to load modules into your system in the first place, they
> > can do pretty much anything they want anyway.  Root gives you the
> > power to hang yourself upside down by the toenails; Linux isn't
> > concerned in the slightest with protecting root from itself - that
> > defeats the point of root itself.
>  
> Good point. And a good question here. Is there anyway that any user other
> than root can recompile a kernel?? I know/or think in theory there's no
> way in hell. But in reality say, and no disrespect intended to anyone,
> maybe a mutant kernel developer could telnet in and do it?

Sure. Anyone can *compile* a kernel, if a compiler is available, and
the user has permission to run it.  Only root has access to /usr/src,
though.  If you wanted to, you could untar a kenel into your home
directory and play with it there without needing permission to do
anything in /usr/src.  It wouldn't affect the rest of your system in
the slightest, though, except taking up hard drive space and wasting
memory and CPU power to build a kernel that won't actually be run.

But to *install* it is another matter.  You need root access to put it
in /boot, and to change /etc/lilo.conf if you need, and to run lilo to
install it, and to reboot the system.  At every step of the way of
installation, filesystem permissions generally make sure that nobody
else can do it.  You can check yourself, on your own system, like I
did:

$ cp blah /boot
cp: cannot create regular file `/boot/blah': Permission denied
$ ls -l /etc/lilo.conf
-rw-r-----    1 root     root         3794 Jun 14 18:45 /etc/lilo.conf
$ ls -l /sbin/lilo
-rwxr-xr-x    1 root     root        58800 May 23 04:48 /sbin/lilo*
$ lilo
/etc/lilo.conf: Permission denied
$ shutdown -r now
shutdown: must be root.

The goal as a sysadmin is to make sure that nobody can just randomly
telnet in and do that sort of thing as root.  There's a file,
/etc/securetty, which specifies to the login program the terminals
root is allowed to log in on.  Even if you had the right password, you
still couldn't get in from off-site, by default.  There are multiple
levels of protection you can take, as well.  Servers run by inetd can
use TCP wrappers, and /etc/hosts.allow and hosts.deny describe rules
for which IPs can get access to which servers.  Packet filtering in
the kernel by firewalling rules is another way, and all these put
together are protection against someone getting root access from
outside.

*Always* disable telnet and use SSH.  Anybody listening to network
traffic can see your password quite plainly when you type it in over
telnet.  You can get a windows SSH client too, there's a good one I've
used called PuTTY.

Perhaps you remember the flamewar on the BLUG list recently about
firewalls.  The fewer servers you run, the less able someone will be
to get in and mess things up.  It's quite rare that there's a kernel
bug that someone can exploit to get in through a bug in the networking
stack.  Peer review, and all that.

> > That's a reasonable goal, especially for firewalls and servers.  Just
> > remember that if the number of things you need grows, you might end up
> > putting things back in that you took out.  It's still a good
> > philosophy, though perhaps slightly less so for a desktop system.  
> 
> I am running a couple services. The final producted is served remotely,
> but maybe ist's that  little bit of control freak in me that would feel
> much more comfortable knowing EXACTLY what's running and when. Oh, and
> what can be executed. I think it's more the inquiring minds thing. I'm
> that way with every system I run. I'd rather re-load something than to
> have something sitting there not knowing what it does.

Sure.  If you're really worried about things changing out from under
you, have a look at Tripwire.  http://www.tripwire.com/

> > > And I'm not the type that can read a book and know what
> > > everything does, no adrenaline involved :}.
> > 
> > It's hard to read a technical book and get something out of it without
> > applying it at the same time.  I recommend O'Reilly's "Unix Power
> > Tools" for learning about shells and the more common of the
> > command-line tools.  Find the HOWTOs that discuss things you want to
> > know more about, and try applying them at the same time.
> 
> I just started a temp position coding html today and all I did was read
> orientation type stuff. Ready to fall asleep. The job seems great and
> I understand the training part. It's just tough for me. I've been pointing
> and clicking for a long time. Not clicking and reading.

I end up doing a lot more typing than clicking.

> > I've personally found adrenalin less useful around computers, as it
> > makes me tend to hit 'Enter' before I've stared at the command long
> > enough to decide if it'll actually do what I want.  And caffeine makes
> > me twitch more than it keeps me awake.  Ah, well.
> 
> Funny my girlfriend and I were laughing about the "first day jitters" and
> working on a terminal. 
> 
> <hhttmmll>
> <hheeaadd>
> <ttiittllee>
> <//ttiittllee>
> </hheeaadd>

Heh.  Given your interest in web design, you might either already know
about or be interested in a certain site:
http://www.webpagesthatsuck.com/

--
Chris Riddoch
socket at peakpeak.com