|
|
| Author |
Message |
| 25 new of 547 responses total. |
lk
|
|
response 296 of 547:
| 
May 20 07:00 UTC 2003 |
Maybe you'll dream up another solution, like disabling the audio in the
BIOS so OpenBSD will never see it in the first place...?
(I suppose it could be a jumper on the motherboard if not a BIOS option.)
|
janc
|
|
response 297 of 547:
|
May 20 11:24 UTC 2003 |
Yeah Leeron! There is a thing in the BIOS to disable the Audio Controller,
and with that turned off, we can boot.
I'd still like to know how to tell OpenBSD to boot off something else.
It seems to sometimes show a "boot>" prompt briefly, and if you type
something then it won't fill it in itself. However, when I started
booting off the CD, typed "boot wd0a:/bsd -c" at the boot> prompt,
it went ahead and booted off the CD anyway. Well, I'll get plenty more
chances to experiment with this.
In the true OpenBSD spirit, after all this work, it greets me by telling me
I'm an idiot:
Don't login as root, use su
Root's the only account on the system, and that's a comma splice, you idiots.
Sorry, I have personality conflicts with OpenBSD.
|
cross
|
|
response 298 of 547:
|
May 20 12:49 UTC 2003 |
Most of the world has personality conflicts with OpenBSD. Hey, disabling
the audio device in the BIOS; I said that in #293!
Comma splices are bad, use semicolons.
|
cross
|
|
response 299 of 547:
|
May 20 12:51 UTC 2003 |
So Jan, just so I can be sure I understand what's going on; a minimal
OpenBSD installation is on the IDE drive, and it's seeing all the
devices now?
|
janc
|
|
response 300 of 547:
|
May 20 14:45 UTC 2003 |
Yup. Staff has been informed, John Remmers has successfully logged in.
My next step is to write some little scripts to copy data around fiercely
on the three SCSI disks, just to increase my confidence that the controller
really is working right with multiple drives.
Yeah, you did say that didn't you? I was way too sleepy last night.
|
remmers
|
|
response 301 of 547:
|
May 20 14:50 UTC 2003 |
Yep, I logged in and created myself a "remmers" account.
|
janc
|
|
response 302 of 547:
|
May 20 15:42 UTC 2003 |
Thought I'd so a survey of suid/sgid programs, many of which might have to
be moved if we do an /suidbin directory. There's a number of them, but many
don't actually need to be SUID on Grex (the ones marked 'X' in the list
below should probably lose their suid bits or not be moved to suidbin).
SUID files:
X -r-sr-xr-x 1 root bin /sbin/ping
X -r-sr-xr-x 1 root bin /sbin/ping6
X -r-sr-x--- 1 root operator /sbin/shutdown
-r-sr-xr-x 3 root bin /usr/bin/chfn
-r-sr-xr-x 3 root bin /usr/bin/chpass
-r-sr-xr-x 3 root bin /usr/bin/chsh
X -r-sr-sr-x 1 root daemon /usr/bin/lpr
X -r-sr-sr-x 1 root daemon /usr/bin/lprm
-r-sr-xr-x 1 root bin /usr/bin/passwd
X -r-sr-xr-x 1 root bin /usr/bin/rsh
-r-sr-xr-x 1 root bin /usr/bin/su
-r-sr-xr-x 1 root bin /usr/bin/sudo
? -r-sr-xr-x 1 root auth /usr/libexec/auth/login_chpass
? -r-sr-xr-x 1 root auth /usr/libexec/auth/login_krb4
? -r-sr-xr-x 1 root auth /usr/libexec/auth/login_krb4-or-pwd
? -r-sr-xr-x 1 root auth /usr/libexec/auth/login_krb5
? -r-sr-xr-x 1 root auth /usr/libexec/auth/login_krb5-or-pwd
? -r-sr-xr-x 1 root auth /usr/libexec/auth/login_lchpass
? -r-sr-xr-x 1 root auth /usr/libexec/auth/login_passwd
-r-sr-xr-x 1 root bin /usr/libexec/lockspool
-r-sr-xr-x 1 root bin /usr/libexec/ssh-keysign
? -r-sr-sr-x 1 root authpf /usr/sbin/authpf
X -r-sr-xr-- 1 root network /usr/sbin/ppp
X -r-sr-xr-- 1 root network /usr/sbin/pppd
X -r-sr-xr-- 1 root network /usr/sbin/sliplogin
X -r-sr-xr-x 1 root bin /usr/sbin/timedc
X -r-sr-xr-x 1 root bin /usr/sbin/traceroute
X -r-sr-xr-x 1 root bin /usr/sbin/traceroute6
SGID files:
X -r-xr-sr-x 4 root crontab /usr/bin/at
X -r-xr-sr-x 4 root crontab /usr/bin/atq
X -r-xr-sr-x 4 root crontab /usr/bin/atrm
X -r-xr-sr-x 4 root crontab /usr/bin/batch
X -r-xr-sr-x 1 root crontab /usr/bin/crontab
? -r-xr-sr-x 1 root kmem /usr/bin/fstat
-r-xr-sr-x 1 root auth /usr/bin/lock
X -r-xr-sr-x 1 root daemon /usr/bin/lpq
? -r-xr-sr-x 1 root _lkm /usr/bin/modstat
? -r-xr-sr-x 1 root kmem /usr/bin/netstat
-r-xr-sr-x 1 root auth /usr/bin/skeyaudit
-r-xr-sr-x 1 root auth /usr/bin/skeyinfo
-r-xr-sr-x 1 root auth /usr/bin/skeyinit
-r-xr-sr-x 1 root _sshagnt /usr/bin/ssh-agent
-r-xr-sr-x 1 root kmem /usr/bin/systat
-r-xr-sr-x 1 root kmem /usr/bin/vmstat
-r-xr-sr-x 1 root tty /usr/bin/wall
-r-xr-sr-x 1 root tty /usr/bin/write
-r-xr-sr-x 1 root games /usr/games/atc
-r-xr-sr-x 1 root games /usr/games/battlestar
-r-xr-sr-x 1 root games /usr/games/canfield
-r-xr-sr-x 1 root games /usr/games/cfscores
-r-xr-sr-x 1 root games /usr/games/cribbage
-r-xr-sr-x 1 root games /usr/games/hack
-r-xr-sr-x 1 root games /usr/games/robots
-r-xr-sr-x 1 root games /usr/games/sail
-r-xr-sr-x 1 root games /usr/games/snake
-r-xr-sr-x 1 root games /usr/games/tetris
? -r-xr-sr-x 4 root _token /usr/libexec/auth/login_activ
? -r-xr-sr-x 4 root _token /usr/libexec/auth/login_crypto
? -r-xr-sr-x 1 root _radius /usr/libexec/auth/login_radius
? -r-xr-sr-x 1 root auth /usr/libexec/auth/login_skey
? -r-xr-sr-x 4 root _token /usr/libexec/auth/login_snk
? -r-xr-sr-x 4 root _token /usr/libexec/auth/login_token
-r-xr-sr-x 1 root smmsp /usr/libexec/sendmail/sendmail
X -r-xr-sr-x 1 root daemon /usr/sbin/lpc
X -r-xr-s--- 1 root daemon /usr/sbin/lpd
-r-xr-sr-x 1 root kmem /usr/sbin/pstat
|
janc
|
|
response 303 of 547:
|
May 20 15:43 UTC 2003 |
You know, this is the next Grex hardware item. I should probably move
future comments to a "software" item.
|
janc
|
|
response 304 of 547:
|
May 20 15:46 UTC 2003 |
I've got six processes busily copying files around on the SCSI drives. No
problems at all yet.
|
polytarp
|
|
response 305 of 547:
|
May 20 18:14 UTC 2003 |
You're great, janc.
|
cross
|
|
response 306 of 547:
|
May 20 21:31 UTC 2003 |
Regarding #304; Cool.
Regarding #303; My suggestion is to leave most of the `normal' binaries
that aren't on / (only ping, ping6, and shutdown are) alone and put
copies in /suid/{s,}bin, then put those directories in the user PATH
before the system default directories. As long as /usr and /usr/local
are mounted nosuid, it won't hurt anything if (mode & 06000) != 0 on
some files therein. It also makes it easier than trying to find what
was symlinked where when the system is upgraded.
Some suggestions: there's no reason to keep pstat, vmstat, systat,
modstat, netstat, etc executable by normal users. Definitely that's true
of fstat; that's a privacy violation waiting to happen. ssh-keysign
can be restricted to members. I don't see the need to strip the suid
bit off of shutdown, as that's only executable by root or users in
group operator, and there aren't likely to be many of the latter.
I would only put login_krb5 in /suid/sbin, as that's the only one
that's likely to be useful, if grex really moves to krb5. I would
further disable the skey stuff; I doubt anyone uses or would use it.
Certainly, authpf doesn't need to be executable by normal users, either.
Wall shouldn't be available to normal users, I don't think. If you go
with an alternate mailer like Postfix, then there's no reason to worry
about keeping sendmail sgid. Finally, the games are only sgid to write
high score files. Probably harmless, and I don't see why not to put
them in /suid/bin (or /suid/games, so they can be shut off easily if
there's a problem). Also, going with Kerberos means that stock `passwd'
can be disabled. /usr/bin/lock isn't likely to be useful if Kerberos
is used, either.
I wouldn't worry about ping and ping6 being suid since the only reason
they are is to send ICMP packets, and those would be blocked by the PF
rules preventing non-member users from sending random stuff out onto
the Internet. It's conceivable someone could find another hole in it,
but I think it's highly unlikely.
|
gull
|
|
response 307 of 547:
|
May 20 22:07 UTC 2003 |
Generally Grex doesn't let users use 'ping' at all, from what I've been
able to tell.
|
cross
|
|
response 308 of 547:
|
May 20 22:18 UTC 2003 |
Yes; my point is that the PF filters will take care of that without
modifying anything in the base-system filesystem.
|
gull
|
|
response 309 of 547:
|
May 20 22:19 UTC 2003 |
Ah, I see. But if no one who doesn't have root privilages is allowed to
use it anyway, why keep the setuid bit?
|
cross
|
|
response 310 of 547:
|
May 20 22:21 UTC 2003 |
So that you don't have to remember to turn it off the next time you
upgrade the system. :-) In general, it's more of a hassle to turn
off the setuid bit if it doesn't do anything than to ignore it.
|
lk
|
|
response 311 of 547:
|
May 20 22:25 UTC 2003 |
Dan, Re#298, 293, and others: Dreams can be like that. You never really
know who said what, if it was real... but hey, it worked.
Nonetheless, since you've provided so much other helpful information and
I have not, I'm going to claim credit for this "fix". Afterall, you
phrased it as a question. I said do it! (:
|
cross
|
|
response 312 of 547:
|
May 20 22:37 UTC 2003 |
Another thing.... Grex might have turned off ping to avoid the problem of
a malicious user using the `flood ping' -f option against another host.
This mode sends packets to a remote host as fast as it can; effectively
clogging the network link between the two. On grex's slow connection,
this could clearly be a problem.
However, OpenBSD's version of ping checks that the real user ID is 0 (ie,
you're root) before allowing you to use the -f option for flood pinging.
Given that any program that wants to create an ICMP socket must be running
as root, and that the standard ping doesn't joe user flood ping anymore,
perhaps it'd be acceptible to stop restricting access to ping. Still,
someone might be able to DoS grex by sending a ping request to some big
broadcast address, so maybe it's a good idea to keep restricting it.
|
cross
|
|
response 313 of 547:
|
May 20 22:38 UTC 2003 |
Hrmph, Leeron! :-)
|
janc
|
|
response 314 of 547:
|
May 21 00:19 UTC 2003 |
I have no intention of "remembering" to turn off suid bits. I'm for
documenting it, in this case in the form of a script that does it.
I'd turn off all the suid-root bits that don't need to be on (or leave them
on a nosuid partition where the suid-bit doesn't matter). It's hard to
imagine a security hole turning up in 'ping', but anything is possible.
I'm much less inclined to be aggressive about the sgid scripts.
|
janc
|
|
response 315 of 547:
|
May 21 00:29 UTC 2003 |
I'm not sure if you can use effectively use different RAID strategies on
different partitions without having different disk sets for them, but I'm
still thinking different RAID strategies make sense for different partitions.
I think /usr is another example where data redundancy seems of less value.
I you lose /usr, and you restore it from a month-old backup, you are probably
fine. Just striping seems perfectly adequate for partitions like that.
Where RAID 5 pays off mostly is in places like /var, /bbs, /home.
|
cross
|
|
response 316 of 547:
|
May 21 01:22 UTC 2003 |
Regarding #314; Well, if you keep / as the only partition that honors
the suid bit, then you only have to change permissions on two binaries:
ping and ping6 (I still say ignore shutdown, since only users in group
operator can run it, anyway).
Regarding #315; The thing is that if you lose /usr, the system is
unusable; similarly with /usr/local, /, etc. RAID isn't just about
data security, it's also about availability.
|
janc
|
|
response 317 of 547:
|
May 21 03:05 UTC 2003 |
Right, but that isn't Grex's highest priority. We aren't amazon.com that
can't be off line for a few days without making headlines. Heck, we currently
shut down for backups. If a disk melts down, taking a few days to come back
up is no disaster, if we can do it without loss of data.
If I'd have been at the last board meeting, I'd have argued against the third
SCSI disk. Grex doesn't need that much disk in the near future. But, we've
got the disk, so we might as well use it. I think the best use may be to do
a RAID setup and win a bit better performance and a bit more data security.
Right now I think the strongest argument against using RAID on Grex is the
KISS argument. RAID certainly has benefits, but it adds complexity, and extra
complexity is always a minus. Using RAID means one more potentially buggy
piece of software in a critical function. It means one more complex subsystem
staff members need to understand, administer, and reinstall on every upgrade.
I think a sound argument could be made that the benefits aren't worth the
complexity. Skip RAID. Divide the partitions among the disks and hope the
loads balance out approximately. rsync critical partitions to the IDE disk
frequently. Remember to do backups. We don't lose much by taking that
easier path, and it is significantly simpler to install and administer.
You could do ccd on some partitions, if you want the same performance benefits
(slightly more even) at a lower complexity level.
|
janc
|
|
response 318 of 547:
|
May 21 03:07 UTC 2003 |
All reports about problems with multiple drives on our SCSI controller seemed
to be about really frequent ones. I've had all three drives busy reading and
writing for all they are worth for a day now and have seen no problems at all.
So I think we can probably consider that problem solved. I'll let them grind
for a bit longer though.
|
cross
|
|
response 319 of 547:
|
May 21 05:12 UTC 2003 |
Regarding #317; Well, to me, splitting up partitions is more complex.
Maybe I'm smoking my hair, but it seems a lot simpler conceptually to
think of a RAID as one giant partition that you can chunk up as you
like, and the performance issues and load balancing are yours free.
You get some modicum of resistance to failures as a side benefit.
As for reliability.... RAIDframe has been in OpenBSD for several
years now. It seems just as solid as FFS itself or even soft updates.
Could it go wrong? Yeah, but there could also be bugs lurking in FFS.
Complexity of configuration is pretty simple. One or two configuration
files, and you're basically good to go. The only really annoying thing
is that you can't directly boot from it. But, at the end of the day,
I'm not on grex staff and aren't challenged with keeping it running.
It seems simpler to me, and RAID-5 everywhere seems to fit grex like
a glove (especially if it's planned on a few partitions already), but
that's just me.
|
janc
|
|
response 320 of 547:
|
May 21 12:57 UTC 2003 |
To some degree I'm arguing all sides of the question to make up for the lack
of people arguing. But the large number of Grex staff who have no opinion
on RAID is a bit worrisome.
Administrative complexity hits at three points - first, right now - decide
which RAID setup to use, and implementing it.
Second, on each system upgrade, which we need to reinstall the kernel
customizations and config files. Mostly we can document this and make
a step-by-step procedure that most anyone can follow.
Third, when a disk has a problem, or when we want to change the disk
configuration. RAID can help with problems like this, but only if you know
what you are doing. Doing the wrong thing can hose your data.
In a volunteer run system, the level of knowledge that may be on hand on
the day when a disk dies is unpredictable. It may make sense to keep things
simple so lots of people feel like they can help. This argument applies
equally to Kerberos. Both confer modest benefits that I'm not sure we need,
at the cost of complexity that makes the size of the hump you have to get
over to become an effective system administrator substantially larger.
I fear they will reduce the size of the pool of potential system
administrators.
Or maybe they we make the system cooler and more interesting, thus attracting
more potential system administrators.
I think I may experiment with setting up RAID on Grex2003, just to get a better
feeling for the complexity.
|
