Bill Anderson wrote:
Wouldn't it be great if the Minimal Install option meant what it said? Who seriously believe NIS belongs on a firewall?? Minimal states it is for such things as firewalls
File it as a bug! Or maybe you want to step up and be part of a worthwhile discussion as to re-working of the existing minimal install option. Since it seems its really a more a matter of how the packages are grouped and which groups a minimal install actually installs..its more a policy issue than an expert coding issue. This seems like something we can have a nice lovely little community discussion about...instead of just poking repeatedly at the anaconda maintainer to remove this one package here...or this one other package..or maybe add this one package to minimal. And its certainly a better idea to fix the current minimal install offering than adding another minimal minimal layer beyond the "broken" minimal.
http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00569.html
I think its pretty clear there is room for volunteers on in impacting how the current minimal install behaves. If your serious about "fixing" the current minimal offering, I suggest the interested people make a stab at drawing up a consensus replacement package list, with some discussion as to why you are dropping each package. Those interested could probably go back and forth a few times on what minimal should be "sanely" including and then make a worthwhile bugticket entry...saving some Red Hat developer time to be spent on some higher priority issues. If there is some obvious consensus from the obviously technically literate people who have a need for minimal install as to how to fix the current minimal package list, I doubt their collective best-effort opinions would be completely ignored. But repeating the "one guy wanting one package in/out of minimal" scenario X number of times isn't going to move anything forward. And of course..submitted patches would probably even less ignored then a consensus best effort essay on the matter.
-jef"put up or..."spaleta
On Thursday, Aug 21, 2003, at 16:38 Asia/Jerusalem, Jef Spaleta wrote:
Bill Anderson wrote:
Wouldn't it be great if the Minimal Install option meant what it said? Who seriously believe NIS belongs on a firewall?? Minimal states it is for such things as firewalls
File it as a bug! Or maybe you want to step up and be part of a worthwhile discussion as to re-working of the existing minimal install option. Since it seems its really a more a matter of how the packages are grouped and which groups a minimal install actually installs..its more a policy issue than an expert coding issue. This seems like something we can have a nice lovely little community discussion about...instead of just poking repeatedly at the anaconda maintainer to remove this one package here...or this one other package..or maybe add this one package to minimal. And its certainly a better idea to fix the current minimal install offering than adding another minimal minimal layer beyond the "broken" minimal.
It was never my (or anyone else's) intention to poke repeatedly at any engineer or person with regard to this. I don't know why you keep bringing this topic up with a negative connotation. What I did in fact intend to was maybe initiate some "nice lovely community discussion" about the packages included in the minimal install. I think there is room to work on it, and we can definitely have certain things removed from there.
http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00569.html
The point about windows xp is very valid. I barely ever use windows but ive heard the same thing. In RH anyhowm, I'm sure many of us are doing a minimal install and then starting to remove things, right off the bat.
I think its pretty clear there is room for volunteers on in impacting how the current minimal install behaves. If your serious about "fixing" the current minimal offering, I suggest the interested people make a stab at drawing up a consensus replacement package list, with some discussion as to why you are dropping each package.
I'm on board is anyone else interested.
--Jack
On Thu, Aug 21, 2003 at 09:38:09AM -0400, Jef Spaleta wrote:
File it as a bug! Or maybe you want to step up and be part of a worthwhile discussion as to re-working of the existing minimal install option. Since it seems its really a more a matter of how the packages are grouped and which groups a minimal install actually installs..its more a policy issue than an expert coding issue. This seems like something we can have a nice lovely little community discussion about...instead of just poking repeatedly at the anaconda maintainer to remove this one package here...or this one other package..or maybe add this one package to minimal. And its certainly a better idea to fix the current minimal install offering than adding another minimal minimal layer beyond the "broken" minimal.
http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00569.html
This discussion always tends to conflate different notions of "minimal".
The question is "minimal" w.r.t what criterion? Is it the bare list of packages necessary to get to a login prompt on a standalone machine? Is it a networked host? Is documentation included? Manpages? Info files? /usr/share/doc?
I'd like to see a "bootstrap configuration" that installs enough that I can install more using up2date or yum. That generally means "basic networking (and firewalling)" + any specifics needed to get my host connected to my network or ISP (i.e., ppp, dhcp, etc.).
Beyond that, agreement tends to dissolve, because intended uses vary widely. This is where the Gentoo model does a good job of factoring the requirements, because I may want to install a bunch of packages, keep the manpages and info files, but eliminate /usr/share/doc, and shun X/KDE/GNOME.
Doing this in a binary distribution means much finer packaging. Red Hat Linux has historically packed a lot into a few packages (e.g., Perl), whereas other RPM-based distros break it all out into individual sub-packages (hundreds of them!). Separating packages into executables and libraries is a good idea not only because it allows multiple libfoo* installs, but also because it saves space when all that one wants are the libs, and not the default front-end application, which may have additional dependencies.
[And then there is kernel-utils -- lots of unrelated binaries, all of which are quickly out of date, and complicate the installation of superior tools like smartmontools. One should try mightily to decouple code that is hardware-dependent, since things like x86info and smartctl change with each release of a new processor or SCSI/ATA/SMART revision.]
Regards,
Bill Rugolsky
On Thursday, Aug 21, 2003, at 18:09 Asia/Jerusalem, Bill Rugolsky Jr. wrote:
On Thu, Aug 21, 2003 at 09:38:09AM -0400, Jef Spaleta wrote:
File it as a bug! Or maybe you want to step up and be part of a worthwhile discussion as to re-working of the existing minimal install option. Since it seems its really a more a matter of how the packages are grouped and which groups a minimal install actually installs..its more a policy issue than an expert coding issue. This seems like something we can have a nice lovely little community discussion about...instead of just poking repeatedly at the anaconda maintainer to remove this one package here...or this one other package..or maybe add this one package to minimal. And its certainly a better idea to fix the current minimal install offering than adding another minimal minimal layer beyond the "broken" minimal.
http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00569.html
This discussion always tends to conflate different notions of "minimal".
The question is "minimal" w.r.t what criterion? Is it the bare list of packages necessary to get to a login prompt on a standalone machine? Is it a networked host? Is documentation included? Manpages? Info files? /usr/share/doc?
I'd like to see a "bootstrap configuration" that installs enough that I can install more using up2date or yum. That generally means "basic networking (and firewalling)" + any specifics needed to get my host connected to my network or ISP (i.e., ppp, dhcp, etc.).
A bootstrap configuration would be nice, but I dont think it would be for anaconda proper. Maybe there needs to be something like "linux bootstrap". We need to work or this further.
--Jack
On Thu, 2003-08-21 at 09:09, Bill Rugolsky Jr. wrote:
On Thu, Aug 21, 2003 at 09:38:09AM -0400, Jef Spaleta wrote:
File it as a bug! Or maybe you want to step up and be part of a worthwhile discussion as to re-working of the existing minimal install option. Since it seems its really a more a matter of how the packages are grouped and which groups a minimal install actually installs..its more a policy issue than an expert coding issue. This seems like something we can have a nice lovely little community discussion about...instead of just poking repeatedly at the anaconda maintainer to remove this one package here...or this one other package..or maybe add this one package to minimal. And its certainly a better idea to fix the current minimal install offering than adding another minimal minimal layer beyond the "broken" minimal.
http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00569.html
This discussion always tends to conflate different notions of "minimal".
The question is "minimal" w.r.t what criterion? Is it the bare list of packages necessary to get to a login prompt on a standalone machine? Is it a networked host? Is documentation included? Manpages? Info files? /usr/share/doc?
In general, I could agree with this. However, the description on Minimal states "for small router/firewall boxes" which gives us a reasonable expectation.
IMO, part of the problem is that selecting the minimal install there are so many required packages that most firewalls will not need, and some that all firewalls should not have.
IMO, a firewall installation ("minimal") is pretty darned close to a minimal network-ready install. One certainly could use it (after the changes I proposed in another email) as a bootstrap for network add-ons.
Install the minimal, then install yum (or add yum during install), then yum-away. Then create a kickstart config file. Or, select the Minimal, then add individual packages.
Oh, and for those who say "just install and remove... then make a kickstart"...
The problem with the "just install and remove then make a kickstart file" mentality is the "and remove" section. Remove foo and find it relies on bar, eggs, bacon, and spam. So if in the package tool during installation, you have to backtrack and find all these other dependencies and remove them, then try again. It is easier to build then remove.
On Thursday, Aug 21, 2003, at 19:39 Asia/Jerusalem, Bill Anderson wrote:
On Thu, 2003-08-21 at 09:09, Bill Rugolsky Jr. wrote:
On Thu, Aug 21, 2003 at 09:38:09AM -0400, Jef Spaleta wrote:
File it as a bug! Or maybe you want to step up and be part of a worthwhile discussion as to re-working of the existing minimal install option. Since it seems its really a more a matter of how the packages are grouped and which groups a minimal install actually installs..its more a policy issue than an expert coding issue. This seems like something we can have a nice lovely little community discussion about...instead of just poking repeatedly at the anaconda maintainer to remove this one package here...or this one other package..or maybe add this one package to minimal. And its certainly a better idea to fix the current minimal install offering than adding another minimal minimal layer beyond the "broken" minimal.
http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00569.html
This discussion always tends to conflate different notions of "minimal".
The question is "minimal" w.r.t what criterion? Is it the bare list of packages necessary to get to a login prompt on a standalone machine? Is it a networked host? Is documentation included? Manpages? Info files? /usr/share/doc?
In general, I could agree with this. However, the description on Minimal states "for small router/firewall boxes" which gives us a reasonable expectation.
True. I think router/firewall in the description is a bit misleading. You can either change the packages or change the description, hence, we should change the packages.
Oh, and for those who say "just install and remove... then make a kickstart"...
The problem with the "just install and remove then make a kickstart file" mentality is the "and remove" section. Remove foo and find it relies on bar, eggs, bacon, and spam.
That's definately quote of the year. Who rocks? Bill Rocks!
--Jack
On Thu, 2003-08-21 at 07:38, Jef Spaleta wrote:
Bill Anderson wrote:
Wouldn't it be great if the Minimal Install option meant what it said? Who seriously believe NIS belongs on a firewall?? Minimal states it is for such things as firewalls
File it as a bug! Or maybe you want to step up and be part of a worthwhile discussion as to re-working of the existing minimal install option. Since it seems its really a more a matter of how the packages are grouped and which groups a minimal install actually installs..its more a policy issue than an expert coding issue. This seems like something we can have a nice lovely little community discussion
I thought that was what we are doing here.
about...instead of just poking repeatedly at the anaconda maintainer to remove this one package here...or this one other package..or maybe add this one package to minimal. And its certainly a better idea to fix the current minimal install offering than adding another minimal minimal layer beyond the "broken" minimal.
I have not suggested anything of the sort you are saying here. I stated a few packages I think are not part of a minimal install intender for "small routers or firewalls" as it was listed in the options, and why. Indeed, it is not my understanding that the maintainer of Anaconda even chooses these package lists. IIRC this thread correctly, it was you who went all sarcastic on things.
Here is a short, quick list of what I see needs to be removed from an install "for creating small router/firewall boxes": aspell aspell-en autofs dhclient finger irda-utils mt-st mtools krb5-workstation nfs-utils pam_smb rsh # should not be a default or mandatory install at all jwhois wget ypbind unix2dos kudzu # do not generally find router/firewall boxes w/changing hardware at #firewalls/routers not usually using at commands parted #firewalls are pretty static partition-wise, remove sudo # plagued w/security concerns and not useful on a router/firewall talk # TALK!?!?!?! on a FIREWALL??!?
Why those packages gone? Routers/Firewalls should not (and generally *do not*) do wgets, participate in Nothing Is Secure(NIS), manipulate dos files, finger other machines, run infrared equipment, act as a DHCP *client*, automount remote NFS shares, do spell checking, authenticate against SMB for users, perform whois lookups, etc..
The "dialup" group should also not be *required*, it should be optional.
The following packages should be removed or made optional instead of default/mandatory:
dos2unix #Optional, non-selected-by-default eject #Optional, non-selected-by-default gpm #Optional, non-selected-by-default kernel-pcmcia-cs #Optional, non-selected-by-default
apmd #Optional, non-selected-by-default dump#Optional, non-selected-by-default ftp #Optional, non-selected-by-default mtr #Optional, non-selected-by-default nss_ldap #Optional, non-selected-by-default pam_krb5 #Optional, non-selected-by-default pidentd #Optional, non-selected-by-default reiserfs-utils # not all routers/firewalls will use this FS rp-pppoe #Optional, non-default jfsutils # not all routers/firewalls will use this FS sendmail # router/firewall, not email server slocate #Optional, maybe default but unselectable specspo # firewall/router not used to make RPMS! tcsh #Optional, non-selected-by-default telnet #Optional, non-default traceroute #Optional, non-selected-by-default up2date #Optional wireless-tools #*most* will not need them: optional, non-default lha #Optional, non-selected-by-default bc # firewall/router, not calculator lftp #Optional, non-selected-by-default openssh-clients #Optional, non-selected-by-default
Why the last one, you may ask? IMO, it is bad security policy to have your firewall able to log in to other machines.
A minimal install should provide no external services beyond SSH, especially when listed as a firewall/router install.
Well, how is that for "bootstrapping" this discussion?
On Thu, Aug 21, 2003 at 10:22:27AM -0600, Bill Anderson wrote:
Why those packages gone? Routers/Firewalls should not (and generally *do not*) do wgets, participate in Nothing Is Secure(NIS), manipulate dos files, finger other machines, run infrared equipment, act as a DHCP *client*, automount remote NFS shares, do spell checking, authenticate against SMB for users, perform whois lookups, etc..
Nearly *every* residential dialup, DSL, and cable modem user acquires an address via DHCP, so a firewall router is most definitely a DHCP *client*.
Regards,
Bill Rugolsky
On Thu, 2003-08-21 at 10:30, Bill Rugolsky Jr. wrote:
On Thu, Aug 21, 2003 at 10:22:27AM -0600, Bill Anderson wrote:
Why those packages gone? Routers/Firewalls should not (and generally *do not*) do wgets, participate in Nothing Is Secure(NIS), manipulate dos files, finger other machines, run infrared equipment, act as a DHCP *client*, automount remote NFS shares, do spell checking, authenticate against SMB for users, perform whois lookups, etc..
Nearly *every* residential dialup, DSL, and cable modem user acquires an address via DHCP, so a firewall router is most definitely a DHCP *client*.
Well around here it is the opposite. Around here they are told to use a static IP (it's always the same IP, makes support easier I suppose) and their cable/dsl box does the DHCP client side. So put dhclient as optional.
On Thu, 21 Aug 2003, Bill Anderson wrote:
Here is a short, quick list of what I see needs to be removed from an install "for creating small router/firewall boxes":
what your list is really pointing out is that the meaning of minimal is subjective. Even for a router / firewall.
Just for a few examples:
krb5-workstation
might be good on a router -- give you secure in-band management capabilities
wget
I definitely want this on a router
A minimal install should provide no external services beyond SSH, especially when listed as a firewall/router install.
a firewall shouldn't provide any external services. manage them out-of-band
What should be a default, or even a minimal, is highly subjective. Perhaps what's needed is a better definition of who / what minimal is intended for, b/c right now it doesn't really suit anyone.
later, chris
On Thu, 2003-08-21 at 10:33, Chris Ricker wrote:
On Thu, 21 Aug 2003, Bill Anderson wrote:
Here is a short, quick list of what I see needs to be removed from an install "for creating small router/firewall boxes":
what your list is really pointing out is that the meaning of minimal is subjective. Even for a router / firewall.
Actually, there are a lot of objective ones. Calculators, NFS, automounting NFS shares, participating in NIS, creating and manipulating dos filesystems, converting unix line endings to dos line endings. None of these are part of a what a firewall or router do. Nor do they serve as "talk" stations, or have a need for spell-checking things.
Just for a few examples:
krb5-workstation
might be good on a router -- give you secure in-band management capabilities
The package itself in it's description says it is for workstations. A firewall/router is not a network management station. Looking at the list of files it provides, I see kerberized versions of rcp, rlogin, uuclient, telnet, rsh, ftp, etc. All not part of what a router/firewall does.
X "might be good" on a router/firewall too as it provides nice graphical tools for system management. But those selecting "minimal" that is "good for small routers/firewalls" are not expecting to get "might be good" packages.
Firewalls and routers route packets. They do not manage networks or services, nor provide them.
wget
I definitely want this on a router
Why? Why should a router/firewall be downloading web pages, etc.?
A minimal install should provide no external services beyond SSH, especially when listed as a firewall/router install.
a firewall shouldn't provide any external services. manage them out-of-band
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
What should be a default, or even a minimal, is highly subjective. Perhaps what's needed is a better definition of who / what minimal is intended for, b/c right now it doesn't really suit anyone.
Well, it does say what it is intended for, it just doesn't live up to (or down to) that claim. :(
Particularly during install, If you have something you want to add because it "might be good" that is easier than removing a bunch of things with dependency trees.
On Thu, Aug 21, 2003 at 11:11:30AM -0600, Bill Anderson wrote:
Why? Why should a router/firewall be downloading web pages, etc.?
To get the errata RPMS, when you have not installed up2date or yum (and python along with it)?
Let's not throw out the baby ...
-Bill Rugolsky
On Thu, 2003-08-21 at 11:17, Bill Rugolsky Jr. wrote:
On Thu, Aug 21, 2003 at 11:11:30AM -0600, Bill Anderson wrote:
Why? Why should a router/firewall be downloading web pages, etc.?
To get the errata RPMS, when you have not installed up2date or yum (and python along with it)?
Uhh ftp? Note that I did include 2 ftp clients as options (actually changed them to options).
Also, in general one should already have them downloaded and put on the test server before throwing them on the firewall, so you can just scp them over from there. Or if you choose to not allow incoming ssh/scp install the (optional) openssh-clients and scp from the test machine. ;)
Or, you could forgo all of the above and tell RPM to install the rpm via ftp url as opposed to local file system.
On Thu, 21 Aug 2003, Bill Anderson wrote:
Uhh ftp? Note that I did include 2 ftp clients as options (actually changed them to options).
why would you possibly permit ftp clients, but not http clients? ftp is even less secure than http -- it makes no sense to allow the former, but not the latter, on security grounds
later, chris
On Thu, 2003-08-21 at 11:52, Chris Ricker wrote:
On Thu, 21 Aug 2003, Bill Anderson wrote:
Uhh ftp? Note that I did include 2 ftp clients as options (actually changed them to options).
why would you possibly permit ftp clients, but not http clients? ftp is even less secure than http -- it makes no sense to allow the former, but not the latter, on security grounds
I didn't say disallow it based on security grounds, but on "minimal install" grounds, so to speak. If I were to base it on security grounds I would use neither http or ftp for this, and thus install neither. Oh, and you can use an HTTP URL for rpm installs and upgrades as well. So there you go, install neither wget or ftp and still be able to do the upgrades. I would not transfer config data over ftp/http anyway, on security grounds.
On Thursday, Aug 21, 2003, at 20:52 Asia/Jerusalem, Chris Ricker wrote:
On Thu, 21 Aug 2003, Bill Anderson wrote:
Uhh ftp? Note that I did include 2 ftp clients as options (actually changed them to options).
why would you possibly permit ftp clients, but not http clients? ftp is even less secure than http -- it makes no sense to allow the former, but not the latter, on security grounds
This is a moot point. You can install rpm from ftp.
--Jack
On Thu, 21 Aug 2003, Bill Anderson wrote:
Just for a few examples:
krb5-workstation
might be good on a router -- give you secure in-band management capabilities
The package itself in it's description says it is for workstations.
Wrong one. I wanted pam_krb5, which was also on your list. Makes sense on interior routers (as might ssh, for the same reasons/uses), doesn't on exterior.
I definitely want this on a router
Why? Why should a router/firewall be downloading web pages, etc.?
to download files to it when I'm setting it up, patching it, etc.
A minimal install should provide no external services beyond SSH, especially when listed as a firewall/router install.
a firewall shouldn't provide any external services. manage them out-of-band
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
I'm disagreeing. The last thing a fw should do is run a service, let alone one with the security history of ssh.... Manage over serial.
later, chris
On Thu, 21 Aug 2003, Chris Ricker wrote:
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
I'm disagreeing. The last thing a fw should do is run a service, let alone one with the security history of ssh.... Manage over serial.
Disagree. Set your access controls in /etc/hosts.allow for sshd and you're done :-)
When I was builing firewalls, I added a default deny for sshd in /etc/hosts.allow in %post, and recommended to add hosts if necessary in /etc/motd.
There is certainly a need for management, and out-of-band in this type of devices is certainly a non-starter.
On Thu, 21 Aug 2003, Pekka Savola wrote:
On Thu, 21 Aug 2003, Chris Ricker wrote:
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
I'm disagreeing. The last thing a fw should do is run a service, let alone one with the security history of ssh.... Manage over serial.
Disagree. Set your access controls in /etc/hosts.allow for sshd and you're done :-)
and then join the OpenSSL / OpenSSH exploit train.... No, thanks!
This is all just proving my point, which was that no one can even agree on what a minimal machine should be.
later, chris
On Thu, 2003-08-21 at 11:55, Chris Ricker wrote:
On Thu, 21 Aug 2003, Pekka Savola wrote:
On Thu, 21 Aug 2003, Chris Ricker wrote:
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
I'm disagreeing. The last thing a fw should do is run a service, let alone one with the security history of ssh.... Manage over serial.
Disagree. Set your access controls in /etc/hosts.allow for sshd and you're done :-)
and then join the OpenSSL / OpenSSH exploit train.... No, thanks!
This is all just proving my point, which was that no one can even agree on what a minimal machine should be.
Actually, at this point this part of the thread is a security discussion, not a minimum install discussion.
Chris Ricker wrote:
On Thu, 21 Aug 2003, Pekka Savola wrote:
On Thu, 21 Aug 2003, Chris Ricker wrote:
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
I'm disagreeing. The last thing a fw should do is run a service, let alone one with the security history of ssh.... Manage over serial.
Disagree. Set your access controls in /etc/hosts.allow for sshd and you're done :-)
and then join the OpenSSL / OpenSSH exploit train.... No, thanks!
This is all just proving my point, which was that no one can even agree on what a minimal machine should be.
"exploit train?" hmm, you don't seem to be quite up to speed on openssh - I suppose you haven't heard about privelege separation etc? openssh is just about the most secure connection method out there.
What do you propose for remote shell access, telnet?
Joe
On Thu, 21 Aug 2003, Joe wrote:
"exploit train?" hmm, you don't seem to be quite up to speed on openssh
No, you're not if you think it doesn't have security problems
Best thing available? Probably. Is that best good enough? That's debatable, though not on this list ;-)
What do you propose for remote shell access, telnet?
Nothing. Physical / serial console only.
later, chris
On Thu, 21 Aug 2003, Chris Ricker wrote:
On Thu, 21 Aug 2003, Pekka Savola wrote:
On Thu, 21 Aug 2003, Chris Ricker wrote:
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
I'm disagreeing. The last thing a fw should do is run a service, let alone one with the security history of ssh.... Manage over serial.
Disagree. Set your access controls in /etc/hosts.allow for sshd and you're done :-)
and then join the OpenSSL / OpenSSH exploit train.... No, thanks!
I'm puzzled by this point. These would be local vulnerabilities. There will always be those, and it can be mitigated by keeping the system up-to-date.
If you haven't heard, hosts.allow activates the access controls very, very early in the process. You really can't exploit OpenSSH using that: 1) no SSH protocol processing happens before that, and 2) no input is received or processed before that.
You rely on tcp-wrappers though, but you can reinforce that by a firewall rule if you want to.
Oh wait, then you join the iptables vulnerability train! :-)
On Thu, 21 Aug 2003, Pekka Savola wrote:
and then join the OpenSSL / OpenSSH exploit train.... No, thanks!
I'm puzzled by this point. These would be local vulnerabilities. There will always be those, and it can be mitigated by keeping the system up-to-date.
Not so. They're remote exploits from anywhere which can connect to OpenSSH.
If you haven't heard, hosts.allow activates the access controls very, very early in the process. You really can't exploit OpenSSH using that: 1) no SSH protocol processing happens before that, and 2) no input is received or processed before that.
a) tcp wrappers is circumventable. How easily depends on how it's configured.... b) you're still attackable from any place you list in hosts.allow, even if tcp wrappers isn't being bypassed. firewalls can be attacked from inside as well as from out....
*shrug* IMHO, it's worth the trouble to manage some firewalls out-of-band. In yours, it's not.
later, chris
On Thu, 2003-08-21 at 14:52, Chris Ricker wrote:
On Thu, 21 Aug 2003, Pekka Savola wrote:
and then join the OpenSSL / OpenSSH exploit train.... No, thanks!
I'm puzzled by this point. These would be local vulnerabilities. There will always be those, and it can be mitigated by keeping the system up-to-date.
Not so. They're remote exploits from anywhere which can connect to OpenSSH.
http://web.mit.edu/kerberos/www/advisories/ Kerberos has had it's "share" of security exploits as well. They include remote compromise vulnerabilities.
Pretty much everything in this category can be said to have had these kinds of problems.
If you haven't heard, hosts.allow activates the access controls very, very early in the process. You really can't exploit OpenSSH using that: 1) no SSH protocol processing happens before that, and 2) no input is received or processed before that.
a) tcp wrappers is circumventable. How easily depends on how it's configured.... b) you're still attackable from any place you list in hosts.allow, even if tcp wrappers isn't being bypassed. firewalls can be attacked from inside as well as from out....
*shrug* IMHO, it's worth the trouble to manage some firewalls out-of-band. In yours, it's not.
In some cases it simply isn't feasible. It is not feasible for example, for me to fly halfway around the world just to do that.
So SSH and krb are optional install, clearly neither are *needed* to do firewall/router stuff. We make them options available to be installed, but *not* part of a minimal *mandatory* install.
On Thursday 21 August 2003 16:13, Bill Anderson wrote:
In some cases it simply isn't feasible. It is not feasible for example, for me to fly halfway around the world just to do that.
So SSH and krb are optional install, clearly neither are *needed* to do firewall/router stuff. We make them options available to be installed, but *not* part of a minimal *mandatory* install.
I agree. There are 3 levels of inclusion to a group, such as minimal (which I assume is made up of @ Core and @ Base).
There is <manditory> where it cannot be removed from the installation, <default> where it can be removed, but is included by default, and <optional> where it is part of the group, and can be included, but is not included by default.
SSH/krb I believe should be <default>.
On Thu, 2003-08-21 at 17:33, Jesse Keating wrote:
On Thursday 21 August 2003 16:13, Bill Anderson wrote:
In some cases it simply isn't feasible. It is not feasible for example, for me to fly halfway around the world just to do that.
So SSH and krb are optional install, clearly neither are *needed* to do firewall/router stuff. We make them options available to be installed, but *not* part of a minimal *mandatory* install.
I agree. There are 3 levels of inclusion to a group, such as minimal (which I assume is made up of @ Core and @ Base).
Close, it's Core, Base (Minimal), and "Dailup"
There is <manditory> where it cannot be removed from the installation, <default> where it can be removed, but is included by default, and <optional> where it is part of the group, and can be included, but is not included by default.
SSH/krb I believe should be <default>.
Yup. Though I'd probably be tempted to put krb in optional. I'm building a list of current and proposed change to Minimal, according to each type (Mandatory, Default, Optional). It should be sent out shortly. Well as soon as I finish writing the script. :)
On Thursday 21 August 2003 17:48, Bill Anderson uttered:
Close, it's Core, Base (Minimal), and "Dailup"
Well right. Dialup being a required of Base. I really don't think that Dialup qualifies as a requirement of Base. I'd file an RFE at the same time we're working on the minimal install to remove Dialup as a requirement of Base. THats why there used to be an option for "Dialup Workstation" or something like that.
There is <manditory> where it cannot be removed from the installation, <default> where it can be removed, but is included by default, and <optional> where it is part of the group, and can be included, but is not included by default.
SSH/krb I believe should be <default>.
Yup. Though I'd probably be tempted to put krb in optional. I'm building a list of current and proposed change to Minimal, according to each type (Mandatory, Default, Optional). It should be sent out shortly. Well as soon as I finish writing the script. :)
I can agree to krb being <optional>. I never use krb myself, jsut thought there were others that wanted it default. Either way doesn't bother me as long as it's removable from the installation options in one (easy)way or another.
I look forward to the new comps.xml and I'll review/add/agree as fit (for my needs). YaY! Community as it should be.
On Friday, Aug 22, 2003, at 02:33 Asia/Jerusalem, Jesse Keating wrote:
On Thursday 21 August 2003 16:13, Bill Anderson wrote:
In some cases it simply isn't feasible. It is not feasible for example, for me to fly halfway around the world just to do that.
So SSH and krb are optional install, clearly neither are *needed* to do firewall/router stuff. We make them options available to be installed, but *not* part of a minimal *mandatory* install.
I agree. There are 3 levels of inclusion to a group, such as minimal (which I assume is made up of @ Core and @ Base).
There is <manditory> where it cannot be removed from the installation, <default> where it can be removed, but is included by default, and <optional> where it is part of the group, and can be included, but is not included by default.
SSH/krb I believe should be <default>.
I'm not a big believer in krb, for a few reasons which are beyond the scope of this discussion, but ill give it to you. Also snmp stuffs must be default. We need to get down to working on a custom comps.xml file. As soon as I have a chance to breathe (and sleep), I'll give it a ago.
--Jack
On Thu, 21 Aug 2003, Chris Ricker wrote:
On Thu, 21 Aug 2003, Pekka Savola wrote:
and then join the OpenSSL / OpenSSH exploit train.... No, thanks!
I'm puzzled by this point. These would be local vulnerabilities. There will always be those, and it can be mitigated by keeping the system up-to-date.
Not so. They're remote exploits from anywhere which can connect to OpenSSH.
You really can't "connect to OpenSSH" before hosts.allow kicks in.
If you haven't heard, hosts.allow activates the access controls very, very early in the process. You really can't exploit OpenSSH using that: 1) no SSH protocol processing happens before that, and 2) no input is received or processed before that.
a) tcp wrappers is circumventable. How easily depends on how it's configured....
Users can always misconfigure their systems. Having IP addresses there is pretty bulletproof, and DNS is also OK.
b) you're still attackable from any place you list in hosts.allow, even if tcp wrappers isn't being bypassed. firewalls can be attacked from inside as well as from out....
Only a fool would allow every internal IP to connect to the firewall. You add your firewall manager workstations or network management hosts there and be done with it. If someone breaks into those first, then you're in pretty deep shit anyway.
On Thu, 2003-08-21 at 11:21, Chris Ricker wrote:
On Thu, 21 Aug 2003, Bill Anderson wrote:
Just for a few examples:
krb5-workstation
might be good on a router -- give you secure in-band management capabilities
The package itself in it's description says it is for workstations.
Wrong one. I wanted pam_krb5, which was also on your list. Makes sense on interior routers (as might ssh, for the same reasons/uses), doesn't on exterior.
Ahh, ok. However, below, you say no logging in remotely at all, so why pam_krb at all then? The only time someone should need to log into a firewall/router, is for administrative purposes. If using a serial connection (directly!) then log in as root, do what you need, and log off. Why not su? Decreased avenue of attack should an attacker manage to get local privileges: Mount everything nosuid. This of course disables 'su root' even if installed.
I definitely want this on a router
Why? Why should a router/firewall be downloading web pages, etc.?
to download files to it when I'm setting it up, patching it, etc.
Why not ftp clients? Or scp from the target storage machine? Or, since in the way you describe it you'll be at the machine for it anyway, floppy or cdrom transfer? [wget has had it's security issues too ;)]
A minimal install should provide no external services beyond SSH, especially when listed as a firewall/router install.
a firewall shouldn't provide any external services. manage them out-of-band
I'm not sure you are disagreeing with me here. Are you saying don't remote log in to a firewall at all, or are you agreeing with me?
I'm disagreeing. The last thing a fw should do is run a service, let alone one with the security history of ssh.... Manage over serial.
OK, I can see that, and in some cases I agree. Although, I am beginning to think that for those getting RH>=10, chances are we are talking about home/SMB users who will not have those capabilities. Thus, SSH would be the next best thing.
The more I look at it ... Small businesses and homes are the likely groups to be running this option. Larger businesses are the target of other RH setups. Homes are exceedingly unlikely to be running Kerberos, and small businesses are also unlikely. Medium businesses only slightly more likely to be running it.
To my understanding (correct me if I'm wrong here) Kerberos only handles auth, it does not encrypt traffic. Thus, moving files to it using kerberos auth will still leave those files plaintext over the wire. Thus, for things like this ssh is a more secure -in general- option. So when I copy over a new /etc/shadow w/o encrypting the traffic, just using krb auth, the file is still plaintext over the wire. (should you be transferring those kinds of things? Sometimes, it is the best choice of those available)
On Thu, 21 Aug 2003, Bill Anderson wrote:
Wrong one. I wanted pam_krb5, which was also on your list. Makes sense on interior routers (as might ssh, for the same reasons/uses), doesn't on exterior.
Ahh, ok. However, below, you say no logging in remotely at all, so why pam_krb at all then? The only time someone should need to log into a firewall/router, is for administrative purposes.
Right, but we're talking about different machines there.
My point, which seems to have been lost in all sorts of security - related sidetracks, was that "firewall / router" is not one category. It's all of:
* interior router in large organization, preferably managed out-of-band over serial but probably managed in-band b/c the realities are what they are
* border router in large organization, possibly managed in-band, possibly out-of-band
* interior firewall in large organization -- you often see both there
* border firewall in large organization -- managed out-of-band, usually
* home firewall, no dhcp
* home firewall, need dhcp
And that's nowhere near to covering all of them, ignores smaller shops (where pretty much everything is managed remotely in-band, often by 3rd parties), is based on my opinions / perceptions / experience -- which probably don't match yours, and uses broad categorizations like border or interior which don't really neatly apply
Having one category that happily fits all those just isn't going to happen.
The closest would be something more like the debian install -- do a minimal install of basically kernel + libc + network (if needed), then boot into the new machine and install the rest using firstboot. And even that's likely to not make everyone happy, since we can't even seem to decide if ftp or http or both clients should be included! ;-)
To my understanding (correct me if I'm wrong here) Kerberos only handles auth, it does not encrypt traffic.
yes, mostly. It does offer encrypted replacements for some protocols (telnet, part of the ftp connection, rprotocols), but generally it's a secure authentication protocol
Thus, moving files to it using kerberos auth will still leave those files plaintext over the wire. Thus, for things like this ssh is a more secure -in general- option.
They're not either-ors. You can use krb for scp authentication, for example.
later, chris
On Thu, 2003-08-21 at 14:47, Chris Ricker wrote:
On Thu, 21 Aug 2003, Bill Anderson wrote:
Wrong one. I wanted pam_krb5, which was also on your list. Makes sense on interior routers (as might ssh, for the same reasons/uses), doesn't on exterior.
Ahh, ok. However, below, you say no logging in remotely at all, so why pam_krb at all then? The only time someone should need to log into a firewall/router, is for administrative purposes.
Right, but we're talking about different machines there.
My point, which seems to have been lost in all sorts of security - related sidetracks, was that "firewall / router" is not one category. It's all of:
...
And that's nowhere near to covering all of them, ignores smaller shops (where pretty much everything is managed remotely in-band, often by 3rd parties), is based on my opinions / perceptions / experience -- which probably don't match yours, and uses broad categorizations like border or interior which don't really neatly apply
Having one category that happily fits all those just isn't going to happen.
We aren't talking about the best desktop or server in general, nor are we talking about the "best" configuration of packages to cover all firewall/router possibilities. We are talking about a "Minimal" option, which means least common denominator for the category. Do all firewall/routers need krb? No? Then it is an option. Do they all need NIS or DHCP? No? Then they optional. Do they need iproute? Yes? Then it's in. In the vast majority of the cases, if you need kerberos, you know that. If you need for some ungodly reason to make your firewall an NIS client, you'll know that. So you add them in.
So you have the default minimum required be the ones that are* least common denominator* (I what is the minimum amount they *all* need), and provide the option to add additional packages as needed by clicking on the "Details" link during the install. Just as is done with most of the install group options.
There are two issue with the install-time option of Minimum "for firewall/router".
1) It installs things that *most* people do not (or should not such as rsh) put on those machines, and provides no way of easily deselecting them. By that I mean you don't play the "OK, let us see if I found all those nasty dependencies this time" game in the installer.
If you take the "install it and remove it" game, you wind up spending even more time to install the system as you remove various bits and pieces, and track down their dependencies.
2) Nearly all of these packages that should be optional are *mandatory* when doing a minimal install.
Not all truck beds fit everybody. So manufacturers offer a variety of beds, and a "Minimal" configuration which includes no bed. Then you can add your own bed to it. This is easier (and cheaper) than "ahh just buy the smallest bed and start removing pieces of the bed you don't want/need". I see no reason why having a minimal installation for a firewall/router has to have pieces that you do not need, pieces that "may" be useful. Give me the choice to add them during the install. Even if you have some of these things selected by default, being able to *unselect* them makes a positive difference.
In fact, this option could be the means to remove all these "I want this install package group X option but this way instead" pleas. You go into the install, select the minimum, and start adding what you need. This is far and away easier. Minimalization is the opposite of feature creep, and it has a final point.
Although, I think one could make an argument for a "stick" option that installs the real basics selected earlier in the process. Where you select Server, Workstation, etc.. there could be a "Base only" option where it installs a base system that allows you to install things (RPM) and connect to a network to get additional packages. Maybe even Base w/Network, Base w/Dialup Networking.
But that's not the same issues as a Minimal Minimal Server install.
As I've noted, of the more than two dozen changes I suggested, only 3/4 have been challenged, and of them only 1/2 continually. :) That tells me that there is plenty of room to trim this "Minimal" firewall/router option down.
So we are hashing back and forth on ssh and kerberos. How about getting a consensus on the rest, such as parted, talk, etc.?
Given the comments on DHCP client, here is the new list I propose:
Remove: aspell aspell-en autofs finger irda-utils mt-st mtools krb5-workstation nfs-utils pam_smb rsh jwhois wget ypbind unix2dos kudzu at parted sudo talk # TALK!?!?!?! on a FIREWALL??!?
Optional in the Minimal Group or Elsewhere: <Dial Up Group? dos2unix eject gpm kernel-pcmcia-cs apmd dump ftp mtr nss_ldap pam_krb5 pidentd reiserfs-utils rp-pppoe jfsutils sendmail slocate specspo tcsh (MAYBE REMOVE?) telnet traceroute up2date wireless-tools lha bc lftp openssh-clients
That is 20 package removals, 26 packages moved to an optional state. That's 46 packages removed from the stock default "Minimum" install. Out of these 46 changes, we seem to be hung on about 10%.
Thus, moving files to it using kerberos auth will still leave those files plaintext over the wire. Thus, for things like this ssh is a more secure -in general- option.
They're not either-ors. You can use krb for scp authentication, for example.
Yes, but then one is back to the openssh exploit train. All abOORD! ;^)
On Thursday 21 August 2003 15:39, Bill Anderson wrote:
Given the comments on DHCP client, here is the new list I propose:
Remove: aspell aspell-en autofs finger irda-utils mt-st mtools krb5-workstation nfs-utils pam_smb rsh jwhois wget ypbind unix2dos kudzu at parted sudo talk # TALK!?!?!?! on a FIREWALL??!?
Some of the above I'd like to see removed from mandatory to optional, but not default.
I'd like to append these for removal from the minimal, moved somewhere else:
tk fbset
Optional in the Minimal Group or Elsewhere: <Dial Up Group? dos2unix eject gpm kernel-pcmcia-cs apmd dump ftp mtr nss_ldap pam_krb5 pidentd reiserfs-utils rp-pppoe jfsutils sendmail slocate specspo tcsh (MAYBE REMOVE?) telnet traceroute up2date wireless-tools lha bc lftp openssh-clients
Add to this:
(if they aren't already optional)
lilo redhat-config-network-tui anacron redhat-logos setserial dos2unix lokkit mailcap rsync star
On Thu, 21 Aug 2003, Chris Ricker wrote:
They're not either-ors. You can use krb for scp authentication, for example.
which reminds me, why is GSSAPI support not enabled in the openssh rpms? bit of a pain to have to rebuild RPMs all the time.
later, chris
regards,
Paul Jakma (paul@dishone.st) said:
They're not either-ors. You can use krb for scp authentication, for example.
which reminds me, why is GSSAPI support not enabled in the openssh rpms? bit of a pain to have to rebuild RPMs all the time.
Unofficial draft standard that changes the interface.
Bill