Cleaning out unneeded executables - Security

This is a discussion on Cleaning out unneeded executables - Security ; Howdy, Well after a few days of compiling, scripting, hacking, tuning, busting, boobytrapping, and generally munging my default linux installation I am nearly ready for public access. This was a _base_ installation of a major distro that will for the ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: Cleaning out unneeded executables

  1. Cleaning out unneeded executables

    Howdy,

    Well after a few days of compiling, scripting, hacking, tuning,
    busting, boobytrapping, and generally munging my default linux
    installation I am nearly ready for public access. This was a _base_
    installation of a major distro that will for the moment remain unnamed.


    "find" tells me a I have something in the neighborhood of 11000,
    (THOUSAND) executable files on my box. Hmm. Obviously strict permission
    are not required to publish an RPM. :-)

    Anybody got a script for recursing through all this unneeded crap and
    sorting the wheat from the chaf?

    -Thanks
    -Matt


  2. Re: Cleaning out unneeded executables

    shrike@cyberspace.org (06-08-06 19:00:04):

    > "find" tells me a I have something in the neighborhood of 11000,
    > (THOUSAND) executable files on my box. Hmm. Obviously strict
    > permission are not required to publish an RPM. :-)
    >
    > Anybody got a script for recursing through all this unneeded crap and
    > sorting the wheat from the chaf?


    Such a lot of executables is very normal for a Linux distribution. I've
    got 4859 executables in my search path only. If I counted all of them
    in my system, I would easily get to numbers like 20000.

    There is no reason to sort them out. Assuming your Linux kernel is
    perfectly secure (which is only theory, but that's enough for now) and
    you've set process and memory limits, those executables can only be
    harmful to the user, who executes them, unless they are SUID root.

    Note: Some of them may come from filesystems, where Unix-style
    permissions are not supported. This includes Windows filesystems as
    well as ISO9660-images without Rock Ridge-extensions. If you didn't
    mount them correctly, then every regular file there appears as being
    executable.


    Regards,
    E.S.

  3. Re: Cleaning out unneeded executables


    Ertugrul Soeylemez wrote:
    > shrike@cyberspace.org (06-08-06 19:00:04):
    >
    > > "find" tells me a I have something in the neighborhood of 11000,
    > > (THOUSAND) executable files on my box. Hmm. Obviously strict
    > > permission are not required to publish an RPM. :-)
    > >
    > > Anybody got a script for recursing through all this unneeded crap and
    > > sorting the wheat from the chaf?

    >
    > Such a lot of executables is very normal for a Linux distribution. I've
    > got 4859 executables in my search path only. If I counted all of them
    > in my system, I would easily get to numbers like 20000.
    >
    > There is no reason to sort them out. Assuming your Linux kernel is
    > perfectly secure (which is only theory, but that's enough for now) and
    > you've set process and memory limits, those executables can only be
    > harmful to the user, who executes them, unless they are SUID root.
    >
    > Note: Some of them may come from filesystems, where Unix-style
    > permissions are not supported. This includes Windows filesystems as
    > well as ISO9660-images without Rock Ridge-extensions. If you didn't
    > mount them correctly, then every regular file there appears as being
    > executable.
    >
    >
    > Regards,
    > E.S.


    I'm not as confident,

    Perhaps I should rephrase... Anybody got any scripts for doing a
    preliminary filesystem audit?

    Yes, thousands of superfluous executables are in your average linux
    distro. "Average" is not adequate for my network. Irony follows shortly
    on the heals of confidence in matters of security.

    IMHO, if it isn't needed, it shouldn't be there.

    -Thanks in advance!
    -Matt


  4. Re: Cleaning out unneeded executables

    shrike@cyberspace.org (06-08-07 06:30:01):

    > Perhaps I should rephrase... Anybody got any scripts for doing a
    > preliminary filesystem audit?


    See .


    > Yes, thousands of superfluous executables are in your average linux
    > distro. "Average" is not adequate for my network. Irony follows
    > shortly on the heals of confidence in matters of security.
    >
    > IMHO, if it isn't needed, it shouldn't be there.


    The 'sort' program mostly is not needed. Would you remove it?
    Unfortunately the most dangerous programs _are_ needed, like 'su' or
    'login', so you couldn't do much about it, anyway. You shouldn't base
    your security on the packages installed. Security holes are elsewhere.

    However, if you only want the packages, that you _really_ need, then
    consider using Gentoo with proper USE-flags, FreeBSD or even LFS. I
    wouldn't recommend LFS, though, because system updates (which _will_ be
    necessary for a secure system) will become a mess.


    Regards,
    E.S.

  5. Re: Cleaning out unneeded executables

    shrike@cyberspace.org wrote:
    > Howdy,
    >
    > Well after a few days of compiling, scripting, hacking, tuning,
    > busting, boobytrapping, and generally munging my default linux
    > installation I am nearly ready for public access. This was a _base_
    > installation of a major distro that will for the moment remain unnamed.
    >
    >
    > "find" tells me a I have something in the neighborhood of 11000,
    > (THOUSAND) executable files on my box. Hmm. Obviously strict permission
    > are not required to publish an RPM. :-)
    >
    > Anybody got a script for recursing through all this unneeded crap and
    > sorting the wheat from the chaf?
    >
    > -Thanks
    > -Matt
    >

    Most modern distributions have package managers that will let you remove
    or add whole packages. You can look at your package manager and see what
    has been installed and remove things you don't want. For example, squid,
    or ftp, etc.

    On a more micro level you could take a look at some of the small
    distributions which have only the very basic utilities and start cutting
    down to that level. Of course if you are running X your basic may still
    be pretty big. Take a look at distros like "damn small linux" or some of
    the floppy only distros.

    Pruning down Linux can be a daunting task full of with problems. The
    package removal method and a good firewall rule set is probably a less
    time consuming approach.

    --
    ----------------
    Barton L. Phillips
    Applied Technology Resources, Inc.
    Tel: (818)652-9850
    Web: http://www.applitec.com

  6. Re: Cleaning out unneeded executables

    shrike@cyberspace.org wrote:

    > Howdy,
    >
    > Well after a few days of compiling, scripting, hacking, tuning,
    > busting, boobytrapping, and generally munging my default linux
    > installation I am nearly ready for public access. This was a _base_
    > installation of a major distro that will for the moment remain unnamed.
    >
    >
    > "find" tells me a I have something in the neighborhood of 11000,
    > (THOUSAND) executable files on my box. Hmm. Obviously strict permission
    > are not required to publish an RPM. :-)
    >
    > Anybody got a script for recursing through all this unneeded crap and
    > sorting the wheat from the chaf?
    >
    > -Thanks
    > -Matt


    The simple fact is, there is no script because nobody can tell what is
    needed by YOU. All of those executable are used by somebody somewhere so
    how is a script writer to know what you want or need?

    Most distributions allow for selection of what programs to be installed.
    most also has an installer that lets you install or remove many packages.
    If you want to limit the number of executables, I would suggest you use the
    package manager for your system (if available) and uninstall any games on
    the system, Decide on the function of your system, if it is a desktop,
    remove any server software unneeded on the desktop. If it is a server, you
    probably could remove desktop software like Office Suite software (unless
    you are serving the software). Then limit the amount of "redundant"
    software by standardizing on one and removing others. If you have both
    OpenOffice and Koffice installed, decide on which you what to use and
    remove the others. The same for windows managers.



    --
    Still waiting for a rational answer from Bittwister to this:
    .

  7. Re: Cleaning out unneeded executables

    wrote in message
    news:1154957401.002060.18880@n13g2000cwa.googlegro ups.com

    >>> "find" tells me a I have something in the neighborhood of 11000,
    >>> (THOUSAND) executable files on my box. Hmm. Obviously strict
    >>> permission are not required to publish an RPM. :-)
    >>>
    >>> Anybody got a script for recursing through all this unneeded crap
    >>> and sorting the wheat from the chaf?

    >>
    >> Note: Some of them may come from filesystems, where Unix-style
    >> permissions are not supported. This includes Windows filesystems as
    >> well as ISO9660-images without Rock Ridge-extensions. If you didn't
    >> mount them correctly, then every regular file there appears as being
    >> executable.

    >
    > I'm not as confident,
    >
    > Perhaps I should rephrase... Anybody got any scripts for doing a
    > preliminary filesystem audit?
    >
    > Yes, thousands of superfluous executables are in your average linux
    > distro. "Average" is not adequate for my network. Irony follows
    > shortly on the heals of confidence in matters of security.


    Try this as root, which will remove all superfluous executables:

    find / -perm +x -exec \rm -rf {} ;

  8. Re: Cleaning out unneeded executables

    "Patrick" (06-08-07 11:59:35):

    > Try this as root, which will remove all superfluous executables:
    >
    > find / -perm +x -exec \rm -rf {} ;


    Do you really think, this is cool or funny? Go back to your favorite
    newspaper's forum or single chat. You're much better off there.

    To people, who don't understand the command above: Do not run it!


    Regards,
    E.S.

  9. Re: Cleaning out unneeded executables

    On 7 Aug 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <1154957401.002060.18880@n13g2000cwa.googlegroups.c om>, shrike@cyberspace.org
    wrote:

    >Ertugrul Soeylemez wrote:
    >> shrike@cyberspace.org (06-08-06 19:00:04):
    >>
    >>> "find" tells me a I have something in the neighborhood of 11000,
    >>> (THOUSAND) executable files on my box. Hmm. Obviously strict
    >>> permission are not required to publish an RPM. :-)


    No indication of the distribution. Some are more featureful than others.
    Packages include groups of files that are somehow related. Thus, a package
    like 'findutils' may include 'find', 'xargs' and more. Something like
    bzip2 may be (and probably is) required for your package manager and
    probably contains five or more executables _besides_ 'bunzip2'. Then
    you get into packages like 'binutils' which may include over a dozen
    executables. And what about your library 'shared object' (.so) files?

    >>> Anybody got a script for recursing through all this unneeded crap and
    >>> sorting the wheat from the chaf?


    A far bigger problem is for you to define what is 'wheat' and what is 'chaff'.
    Everyone does not use their systems for the same things, and therefore the
    definition is a moving target - a phantom.

    >> Such a lot of executables is very normal for a Linux distribution. I've
    >> got 4859 executables in my search path only. If I counted all of them
    >> in my system, I would easily get to numbers like 20000.


    Mine isn't quite that bad, but the concept is similar.

    >> Note: Some of them may come from filesystems, where Unix-style
    >> permissions are not supported. This includes Windows filesystems as
    >> well as ISO9660-images without Rock Ridge-extensions. If you didn't
    >> mount them correctly, then every regular file there appears as being
    >> executable.


    A good point.

    >Perhaps I should rephrase... Anybody got any scripts for doing a
    >preliminary filesystem audit?


    Perhaps it would help to run find with a -atime option in addition to
    the -perm and -type.

    >Yes, thousands of superfluous executables are in your average linux
    >distro. "Average" is not adequate for my network. Irony follows shortly
    >on the heals of confidence in matters of security.


    * Linux From Scratch

    version: 6.1.1
    author: Gerard Beekmans,
    last update: Nov 2005
    available formats:
    1. HTML (read online) (HTML.tar.bz2)
    2. HTML (read online, single file) (HTML.bz2)
    3. HTML (tarred and bzipped package)
    4. PDF (PDF.bz2)
    5. text (txt.bz2)
    6. text (XML.tar.bz2)

    Derived from the popular Linux-From-Scratch-HOWTO, this book
    describes the process of creating your own Linux system from scratch
    from an already installed Linux distribution, using nothing but the
    sources of software that are needed.
    More information can be found at http://www.linuxfromscratch.org.

    >IMHO, if it isn't needed, it shouldn't be there.


    If you know what you will be doing, you can simply do that for several days
    to establish a pattern, then run a 'find / -type f -atime +N -perm +111' and
    see what turns up (where N is the number of days you've run this test). Be
    sure to run the test long enough to catch weekly (or longer) cron jobs. You
    can then remove (or disable) the unused executables. Do this on a test box, as
    you may receive nasty surprises.

    Old guy

  10. Re: Cleaning out unneeded executables

    Ertugrul Soeylemez wrote:

    >
    >
    > "Patrick" (06-08-07 11:59:35):
    >
    >> Try this as root, which will remove all superfluous executables:
    >>
    >> find / -perm +x -exec \rm -rf {} ;

    >
    > Do you really think, this is cool or funny? Go back to your favorite
    > newspaper's forum or single chat. You're much better off there.
    >
    > To people, who don't understand the command above: Do not run it!
    >
    >
    > Regards,
    > E.S.


    Particularly as root

    --
    Dancin' in the ruins tonight
    mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
    Tayo'y Mga Pinoy

  11. Re: Cleaning out unneeded executables

    Ertugrul Soeylemez wrote:

    [putolin]

    > However, if you only want the packages, that you _really_ need, then
    > consider using Gentoo with proper USE-flags, FreeBSD or even LFS. I
    > wouldn't recommend LFS, though, because system updates (which _will_ be
    > necessary for a secure system) will become a mess.
    >
    >
    > Regards,
    > E.S.


    How so?

    I have a LFS 5.0 (server) with paco and it certainly is not a mess.

    --
    Dancin' in the ruins tonight
    mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
    Tayo'y Mga Pinoy

  12. Re: Cleaning out unneeded executables

    > > However, if you only want the packages, that you _really_ need, then
    > > consider using Gentoo with proper USE-flags, FreeBSD or even LFS. I
    > > wouldn't recommend LFS, though, because system updates (which _will_
    > > be necessary for a secure system) will become a mess.

    >
    > How so?
    >
    > I have a LFS 5.0 (server) with paco and it certainly is not a mess.


    LFS 5.0? By 'LFS' I mean a _real_ Linux from scratch system, where you
    build your entire system by hand.


    Regards,
    E.S.

  13. Re: Cleaning out unneeded executables

    Ertugrul Soeylemez wrote:

    >
    >
    >> > However, if you only want the packages, that you _really_ need, then
    >> > consider using Gentoo with proper USE-flags, FreeBSD or even LFS. I
    >> > wouldn't recommend LFS, though, because system updates (which _will_
    >> > be necessary for a secure system) will become a mess.

    >>
    >> How so?
    >>
    >> I have a LFS 5.0 (server) with paco and it certainly is not a mess.

    >
    > LFS 5.0? By 'LFS' I mean a _real_ Linux from scratch system, where you
    > build your entire system by hand.
    >
    >
    > Regards,
    > E.S.


    I did build it myself.
    I configured/compiled/installed/configured/debugged every package installed
    onto the system.
    Wrote many of the boot/configuration scripts me-self.

    I just chose to use the LFS book 5.0 as a guide.
    No sense in reinventing the wheel.
    By using the LFS books as a guide you can build a bare-bones system, you
    will then need to make it useful.
    Using the book just gives you a bootstrap.

    Are you sure you know what LFS really is?
    You cannot install it as you would a distro.

    --
    Dancin' in the ruins tonight
    mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
    Tayo'y Mga Pinoy

  14. Re: Cleaning out unneeded executables

    In comp.os.linux.security shrike@cyberspace.org:
    > Howdy,


    > Well after a few days of compiling, scripting, hacking, tuning,
    > busting, boobytrapping, and generally munging my default linux
    > installation I am nearly ready for public access. This was a _base_
    > installation of a major distro that will for the moment remain unnamed.


    Sure, security reasons I suppose?

    > "find" tells me a I have something in the neighborhood of 11000,
    > (THOUSAND) executable files on my box. Hmm. Obviously strict permission
    > are not required to publish an RPM. :-)


    > Anybody got a script for recursing through all this unneeded crap and
    > sorting the wheat from the chaf?


    It is up to you to decide what is "crap" and what not, if you
    don't know the answer, it is obviously not "crap".

    However, the first updates would break your genius security
    concept, you plan on installing updates? I suppose since your are
    after security.

    If you need/want to delete things use the package manager to
    delete to avoid those problems, hopefully you haven't already
    driven your system into an unmaintainable state?

    Good luck

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 279: The static electricity routing is acting up...

  15. Re: Cleaning out unneeded executables

    Baho Utot (06-08-08 20:57:19):

    > Are you sure you know what LFS really is?
    > You cannot install it as you would a distro.


    Well, that's exactly what I meant. And you won't have a package manager
    with thousands of packages maintained by experienced people. You're
    going to upgrade every single package manually (or via a script). That
    takes a lot of time and is error-prone.


    Regards,
    E.S.

  16. Re: Cleaning out unneeded executables

    Ertugrul Soeylemez wrote:

    >
    >
    > Baho Utot (06-08-08 20:57:19):
    >
    >> Are you sure you know what LFS really is?
    >> You cannot install it as you would a distro.

    >
    > Well, that's exactly what I meant. And you won't have a package manager
    > with thousands of packages maintained by experienced people. You're
    > going to upgrade every single package manually (or via a script). That
    > takes a lot of time and is error-prone.
    >
    >
    > Regards,
    > E.S.


    Provided that the package "really" needs updated.
    For example:

    I have openssh-3.7p1 running on the server, it works and yes does have some
    problems:

    1. Versions affected:

    Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple
    vulnerabilities in the new PAM code. At least one of these bugs
    is remotely exploitable (under a non-standard configuration,
    with privsep disabled).

    The OpenBSD releases of OpenSSH do not contain this code and
    are not vulnerable. Older versions of portable OpenSSH are not
    vulnerable.

    2. Solution:

    Upgrade to Portable OpenSSH 3.7.1p2 or disable PAM
    support ("UsePam no" in sshd_config).

    Due to complexity, inconsistencies in the specification and
    differences between vendors' PAM implementations we recommend
    that PAM be left disabled in sshd_config unless there is a need
    for its use. Sites only using public key or simple password
    authentication usually have little need to enable PAM support.

    Since I don't use PAM and I use public key authentication, iptables and tcp
    wrappers control network/user connects.

    What's the issue?

    Why upgrade it?

    --
    Dancin' in the ruins tonight
    mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
    Tayo'y Mga Pinoy

  17. Re: Cleaning out unneeded executables

    On 2006-08-12, Baho Utot wrote:
    > Ertugrul Soeylemez wrote:
    >> You're
    >> going to upgrade every single package manually (or via a script). That
    >> takes a lot of time and is error-prone.


    > Provided that the package "really" needs updated.
    > For example:
    >
    > I have openssh-3.7p1 running on the server, it works and yes does have some
    > problems:

    [...]
    > Upgrade to Portable OpenSSH 3.7.1p2 or disable PAM
    > support ("UsePam no" in sshd_config).
    >
    > Due to complexity, inconsistencies in the specification and
    > differences between vendors' PAM implementations we recommend
    > that PAM be left disabled in sshd_config unless there is a need
    > for its use. Sites only using public key or simple password
    > authentication usually have little need to enable PAM support.
    >
    > Since I don't use PAM and I use public key authentication, iptables and tcp
    > wrappers control network/user connects.


    > Why upgrade it?


    CVE-2005-2666? CVE-2006-0225?

    --
    Paul Kimoto
    This message was originally posted on Usenet in plain text. Any images,
    hyperlinks, or the like shown here have been added without my consent,
    and may be a violation of international copyright law.

  18. Re: Cleaning out unneeded executables

    Paul Kimoto wrote:

    >
    >
    > On 2006-08-12, Baho Utot wrote:
    >> Ertugrul Soeylemez wrote:
    >>> You're
    >>> going to upgrade every single package manually (or via a script). That
    >>> takes a lot of time and is error-prone.

    >
    >> Provided that the package "really" needs updated.
    >> For example:
    >>
    >> I have openssh-3.7p1 running on the server, it works and yes does have
    >> some problems:

    > [...]
    >> Upgrade to Portable OpenSSH 3.7.1p2 or disable PAM
    >> support ("UsePam no" in sshd_config).
    >>
    >> Due to complexity, inconsistencies in the specification and
    >> differences between vendors' PAM implementations we recommend
    >> that PAM be left disabled in sshd_config unless there is a need
    >> for its use. Sites only using public key or simple password
    >> authentication usually have little need to enable PAM support.
    >>
    >> Since I don't use PAM and I use public key authentication, iptables and
    >> tcp wrappers control network/user connects.

    >
    >> Why upgrade it?

    >
    > CVE-2005-2666?


    SSH, as implemented in OpenSSH before 4.0 and possibly other
    implementations, stores hostnames, IP addresses, and keys in plaintext in
    the known_hosts file, which makes it easier for an attacker that has
    compromised an SSH user's account to generate a list of additional targets
    that are more likely to have the same password or key.

    You can't get to ~/.ssh/known_hosts and the host is not accessible from the
    internet.

    Here's the key:

    server ssh-rsa
    AAAAB3NzaC1yc2EAAAABIwAAAIEAu95PjFYSGpS8t9AWRfRf91 mFcPDBSOwp58bcq00mYa5Fd9/dClulqbd/mW7ZHSEu8VNFNSzRZt5VhhuBXsvbN8k4KWntCR1K/Vg/R0pFIt2hq2u4OFddhiI4TLUDPWjdM8aqfuaz+J+FsDYgTDx4DN oyoFphR+vSeop6siOmXl8=

    > CVE-2006-0225?


    scp in OpenSSH 4.2p1 allows attackers to execute arbitrary commands via
    filenames that contain shell metacharacters or spaces, which are expanded
    twice.

    It is not version 4.2p1

    --
    Dancin' in the ruins tonight
    mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
    Tayo'y Mga Pinoy

  19. Re: Cleaning out unneeded executables

    On 2006-08-13, Baho Utot wrote:
    > Paul Kimoto wrote:
    >> On 2006-08-12, Baho Utot wrote:
    >>> Ertugrul Soeylemez wrote:
    >>>> You're
    >>>> going to upgrade every single package manually (or via a script). That
    >>>> takes a lot of time and is error-prone.


    >>> Provided that the package "really" needs updated.


    >>> I have openssh-3.7p1


    >>> Why upgrade it?


    >> CVE-2006-0225?


    > scp in OpenSSH 4.2p1 allows attackers to execute arbitrary commands via
    > filenames that contain shell metacharacters or spaces, which are expanded
    > twice.
    >
    > It is not version 4.2p1


    Your triage is incomplete: that text doesn't say that older scp's are okay.
    The Debian changelog (4.3p2-1) says:

    : scp (as does rcp, on which it is based) invoked a
    : subshell to perform local to local, and remote to remote copy
    : operations. This subshell exposed filenames to shell expansion twice;
    : allowing a local attacker to create filenames containing shell
    : metacharacters that, if matched by a wildcard, could lead to execution
    : of attacker-specified commands with the privilege of the user running
    : scp

    suggesting that scp may have had this problem ever since it was invented.

    Meanwhile, NIST says:

    : Vulnerable software and versions
    :
    : OpenBSD, OpenSSH, 4.2 p1
    : OpenBSD, OpenSSH, 4.1 p1
    : OpenBSD, OpenSSH, 4.0 p1
    : OpenBSD, OpenSSH, 3.0 p1
    : OpenBSD, OpenSSH, 3.0
    : OpenBSD, OpenSSH, 3.0.1 p1
    : OpenBSD, OpenSSH, 3.0.1
    : OpenBSD, OpenSSH, 3.0.2 p1
    : OpenBSD, OpenSSH, 3.0.2
    : OpenBSD, OpenSSH, 3.1 p1
    : OpenBSD, OpenSSH, 3.1
    : OpenBSD, OpenSSH, 3.2
    : OpenBSD, OpenSSH, 3.2.2 p1
    : OpenBSD, OpenSSH, 3.2.3 p1
    : OpenBSD, OpenSSH, 3.3 p1
    : OpenBSD, OpenSSH, 3.3
    : OpenBSD, OpenSSH, 3.4 p1
    : OpenBSD, OpenSSH, 3.4
    : OpenBSD, OpenSSH, 3.5
    : OpenBSD, OpenSSH, 3.5 p1
    : OpenBSD, OpenSSH, 3.6
    : OpenBSD, OpenSSH, 3.6.1 p1
    : OpenBSD, OpenSSH, 3.6.1 p2
    : OpenBSD, OpenSSH, 3.6.1
    : OpenBSD, OpenSSH, 3.7
    : OpenBSD, OpenSSH, 3.7.1 p2
    : OpenBSD, OpenSSH, 3.7.1
    : OpenBSD, OpenSSH, 3.8
    : OpenBSD, OpenSSH, 3.8.1 p1
    : OpenBSD, OpenSSH, 3.8.1
    : OpenBSD, OpenSSH, 3.9
    : OpenBSD, OpenSSH, 3.9.1 p1
    : OpenBSD, OpenSSH, 3.9.1

    http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-0225

    --
    Paul Kimoto
    This message was originally posted on Usenet in plain text. Any images,
    hyperlinks, or the like shown here have been added without my consent,
    and may be a violation of international copyright law.

  20. Re: Cleaning out unneeded executables

    Baho Utot (06-08-12 12:57:15):

    > > Well, that's exactly what I meant. And you won't have a package
    > > manager with thousands of packages maintained by experienced people.
    > > You're going to upgrade every single package manually (or via a
    > > script). That takes a lot of time and is error-prone.

    >
    > Provided that the package "really" needs updated.
    > For example:
    >
    > [...]
    >
    > What's the issue?
    >
    > Why upgrade it?


    You might miss some advisories. I wouldn't want to subscribe to
    hundrets of mailing lists, and take care of a mail each minute. On the
    other hand, you may be faster than package maintainers, if you do so,
    and don't use too many packages. Both methods have their up- and
    downsides.


    Regards,
    E.S.

+ Reply to Thread
Page 1 of 2 1 2 LastLast