| |||||||||||||
Minimizing packagesMinimizing packagesPosted Jun 23, 2007 1:10 UTC (Sat) by jmorris42 (subscriber, #2203)In reply to: Counting vulnerabilities by dmarti Parent article: Counting vulnerabilities
> reminder that we should be aggressively weeding newly installed systems for unused software.
Always sound advice, but becoming harder to do. The minimum RPM transaction to bootstrap RHEL4's packageset is 75. That gets you rpm installed and not much else. Drop in the next 84 package interdependent bundle and you will have vim-minimal available. There are literally hundreds of packages on a typical system that aren't really being used but can't be removed because some other little used package has a tenuous relationship with it.
Examples:
Servers with no sound capability that must have alsa-lib because gnome-libs and kdebase ultimately depend on it.
Well a RHEL4 server certainly doesn't need ogg support, right? If you stick to the recommended GNOME desktop it doesn't, but kdebase does depend on it.
Don't have a Palm(tm) device? Well you need to keep it installed if you use Evolution.
Or check this dependency trail. On a system running only GNOME, certainly there shouldn't be a need to keep Qt hanging around right? Wrong. Qt is needed by arts, with is needed by gstreamer-plugins -> gnome-applets -> gnome-media -> nautilus-media -> rhythmbox -> gnome-volume-manager -> gnome-session-manager. So remove Qt and by the time the cascade settles gnome is toast.
(Log in to post comments)
Minimizing packages Posted Jun 23, 2007 3:02 UTC (Sat) by mattdm (guest, #18) [Link] But why are you putting *any* desktop environment on your server?
Minimizing packages Posted Jun 23, 2007 4:35 UTC (Sat) by chaneau (subscriber, #6674) [Link] There are legitimate reasons to put a desktop environment on a server, here, for example, I'm in the process of replacing all the PC with thin clients.
Minimizing packages Posted Jun 23, 2007 10:29 UTC (Sat) by mattdm (guest, #18) [Link] Sure, but that's a special case, and in that case, it's no surprise that something in your installed stack of apps requires sound libraries.
Minimizing packages Posted Jun 23, 2007 9:00 UTC (Sat) by pcampe (guest, #28223) [Link] >But why are you putting *any* desktop environment on your server?
You need to install Oracle (I haven't done this in the last 2 years, so maybe I'm wrong, but for sure there are server programs that you could install/use/monitor only with a graphical interface, and for security, licenses, performance reasons you can't work from a remote workstation, eve if "remote" means "in the same LAN").
Minimizing packages Posted Jun 23, 2007 18:36 UTC (Sat) by AJWM (guest, #15888) [Link] > You need to install Oracle
Oracle is _horrible_ as far as that goes. One of our customers runs some Oracle reporting apps that _require_ X Windows to be running (and with xhost+ to the other servers that use the reporting app). Yeah, we can configure Xvfb to do the job, but it's a pain. All this so the Oracle app can do some font rasterizing or something.
Other "management" apps are just as bad, requiring a graphic or browser interface (hello, SANsurfer) to do anything useful. Try that when your server is in a private (10.x.x.x) LAN that requires a couple of intervening ssh servers to get to. Yes, it can be done by setting up the right ssh tunnelling, but it's a pain in the butt compared to command line (and scriptable!) access.
Even amongst the apps in a single distro that DO permit an alternate command line mode, it's inconsistent. up2date-nox vs printconf-tui, anyone?
Okay, rant off.
Minimizing packages Posted Jun 25, 2007 14:38 UTC (Mon) by nix (subscriber, #2304) [Link] It's not even font rasterizing. The thing's getting font metrics and that's all.
(Client-side fonts, guys?)
Minimizing packages Posted Jun 23, 2007 12:26 UTC (Sat) by evgeny (guest, #774) [Link] Solution: Gentoo (or like, source-based distros).
Minimizing packages Posted Jun 27, 2007 20:43 UTC (Wed) by hazelsct (guest, #3659) [Link] Uh, how does that provide any advantage at all? You can remove .rpms or .debs to minimize vulnerabilities as easily as source-based packages (arguably more easily).
Minimizing packages Posted Jun 27, 2007 21:35 UTC (Wed) by ksmathers (guest, #2353) [Link] Package dependencies arise from the configuration options selected on the machine where the developer built the system. Source based distributions do not have arbitrary dependencies. If you build an app without another library present, and if it can configure itself for the lack of library, then it does.
That can't happen effectively in a system of compiled packages, but it is only important if you are a minimalist, or if you tend to use packages from different sources (which might therefor have conflicting binary dependencies.)
Minimizing packages Posted Jun 28, 2007 5:51 UTC (Thu) by evgeny (guest, #774) [Link] > but it is only important if you are a minimalist,
I remember from Debian-3.0 days, when I wanted to install the php-odbc module on a server (no X stuff at all), it attempted to install Gtk+, Corba, etc, plus some of Gnome, only because the ODBC GUI setup utility was linked against all those libs. Call me minimalist...
Minimizing packages Posted Jun 25, 2007 7:23 UTC (Mon) by flewellyn (subscriber, #5047) [Link] I remember this nonsense from the days when I ran Red Hat Linux, back before Fedora and RHEL.I would try to install packages like KDE updates, and naturally they would require print drivers...even though I had no printer. Or, when I wanted to use a GTK package, sometimes the package in question would ask for GNOME...but I didn't USE GNOME at all! SuSE and other RPM- based distros seem to have the same issue. I would have hoped they'd have it fixed by now.
DPKG-based distros seem better at allowing you to select "required" versus "recommended"
Gentoo and other source-based distros, to me, seem to have the best solution: build only with
Minimizing packages Posted Jun 25, 2007 22:03 UTC (Mon) by njs (guest, #40338) [Link] >Gentoo and other source-based distros, to me, seem to have the best solution: build only with what you actually need, and disable features you don't need to use. Thus, excess packages get pruned from the dependency tree and you end up with less clutter (and, not incidentally, fewer possible vulnerabilities).
But the trade-off is that every box ends up running its own unique mix of code. Security-wise, this is good in that it increases diversity (so it's less likely someone will be able to pwn *all* Gentoo boxes), but reduces scrutiny on the actual code and interactions present on any particular box (so it's more likely that any particular Gentoo box *can* be pwned, which is probably what most sysadmins care about more).
Hard to know how much extra risk this is in practice, though; that'd make a lovely study, if anyone can figure out how to measure it.
Minimizing packages Posted Jun 25, 2007 23:05 UTC (Mon) by flewellyn (subscriber, #5047) [Link] But the trade-off is that every box ends up running its own unique mix of code. Security-wise, this is good in that it increases diversity (so it's less likely someone will be able to pwn *all* Gentoo boxes), but reduces scrutiny on the actual code and interactions present on any particular box (so it's more likely that any particular Gentoo box *can* be pwned, which is probably what most sysadmins care about more). Actually, Gentoo does support binary packages, stored on a repository server that can be used to update the other machines in the cluster. I know of several clusters that do exactly this: one machine builds the updates, and then serves the binaries to the other machines. Obviously this really only works if you have a cluster of identical machines, but that's not unusual in a decent-sized server farm. Or a cluster of workstations.
Minimizing packages Posted Jun 26, 2007 4:01 UTC (Tue) by njs (guest, #40338) [Link] I know, but that's not very relevant to what I'm talking about. The issue I'm pointing out is that your particular set of programs each compiled with your particular quirky set of USE flags might have some novel security bug that no-one else noticed. Code that lots of people use tends to be well tested and highly scrutinized; weird and rarely used #ifdef'ed code tends to be just the opposite. This thread is advocating using more of the latter sort of code, and thus might actually increase security exposure. Running that same rarely used code across 10 boxes instead of 1 won't affect how much scrutiny it gets, you need lots of people in lots of different situations to get that.
It's hard to know whether this extra risk is important or just theoretical, though, hence my curiosity about quantifying it...
Minimizing packages Posted Jun 26, 2007 8:21 UTC (Tue) by flewellyn (subscriber, #5047) [Link] I can see how that might theoretically be a problem, but in all honesty, the set of USE flags for aparticular package doesn't have that much crazy variation.
In general, the USE flags tend to correspond to features that can be added or removed via
Setting weird compiler optimization flags in the global make.conf, now, there I can see a source
Minimizing packages Posted Jun 28, 2007 16:21 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] The point is that distro binaries very, very, very seldomly get rebuilt by the distro's users for most other distros. So, if one RHEL4 box is vulnerable in package XYZ due to how package XYZ was configured for RHEL4, then pretty much all RHEL4 users that have that package installed will have that vulnerability on their system.
In contrast, if the same package is available on Gentoo, and it's only vulnerable if you configure XYZ to make use of some other package PDQ, then only Gentoo users who have configured XYZ to use PDQ will be vulnerable. The same goes if you build a bunch of packages from source on any other distro, but only for those packages.
That's the distinction that's being drawn.
The flipside is that there might be some unforseen interaction between packages that a particular Gentoo configuration might expose and that other configurations won't. Since any given configuration will get less scrutiny, there's a higher chance of a given Gentoo box being vulnerable *on the basis of scrutiny alone*. The reality is that that's mostly theoretical, and in general removing features tends to (but does not always) remove vulnerabilities.
Minimizing packages Posted Jun 27, 2007 7:47 UTC (Wed) by HenrikH (guest, #31152) [Link] You are correct in that USE flags would yield a possibility that one runs programs with unknown holes in them, but then the attacker must also be aware of these unknown holes and also know that you compiled your packages with that very specific USE flags.
Not that it gives a warm and fuzzy feeling, but it would still be some uphill for a potential attacker. And more importantly is that thanks to the wide spread of USE flags a lot of previously unknown bugs will be reported (and hopefully fixed) due to the great variety of the users.
Minimizing packages Posted Jun 28, 2007 11:29 UTC (Thu) by aglet (guest, #1334) [Link] Given that dependency definition and management is one of (maybe the most!) important task in preparing a Linux distribution, I have to say I'm disappointed in RedHat. Trying to work out *why* things are installed on the system is always a pain, and the mix of "file", "library" and "package" dependencies makes it worse. It took me a while to figure out what was bloating it out, and how to keep it small, in the end I ended up with this in a kickstart file:%packages --resolvedeps --nobase @ core openssh-server up2date # ... extra packages go here...Including my app support bits & bobs, I wound up with about 180 RPMs or so -- this seems to be about the minimum to have a box that is actually useful. I found rpmgraph helpful in visualising where things were coming from (I used poster to print the diagram out) Perhaps it's better with yum (I'm still on RHEL 4), but I also loathe up2date with a passion. RHN is also annoying -- why no interface that I can use from the command line? I hate having to visit a web page to manipulate the subscriptions, I'm seriously considering wrapping it with Mechanize, then exposing it as a RESTful interface...
|
|||||||||||||