Cleaning out unneeded executables - Security

This is a discussion on Cleaning out unneeded executables - Security ; shrike@cyberspace.org wrote: > Howdy, Thanks to those who actually attempted to help! The box is locked down to my satisfaction finally. The question posted involved perhaps 1% of the the security policy that was actually involved, but a disproportionate amount ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 29 of 29

Thread: Cleaning out unneeded executables

  1. Re: Cleaning out unneeded executables


    shrike@cyberspace.org wrote:
    > Howdy,




    Thanks to those who actually attempted to help!

    The box is locked down to my satisfaction finally. The question posted
    involved perhaps 1% of the the security policy that was actually
    involved, but a disproportionate amount of time was required to deal
    with it.

    I was truly amazed at the number of posts to this thread that were
    malicious, negligent, or pointless.

    I would like to point out to any future readers, that running tight
    machine _is_ helpfull to security if _only_ for the fact that it makes
    filesystem auditing faster and cheaper down the road.

    Yeah a full install is great: until your broken into. Then you start
    wishing you'd done some preperation and ran a cleaner filesystem.
    Organization creates clarity, clarity reduces response time in
    emergencies. It is that simple.

    Cluefullness !~ Complexity

    -Clowns hack where productive people wouldn't bother to tread.
    -Matt


  2. Re: Cleaning out unneeded executables

    Paul Kimoto wrote:

    [putolin]

    > 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
    >


    But in my case it doesn't matter as ssh doesn't face the inet.

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

  3. Re: Cleaning out unneeded executables

    shrike@cyberspace.org wrote:
    > I would like to point out to any future readers, that running tight
    > machine _is_ helpfull to security if _only_ for the fact that it makes
    > filesystem auditing faster and cheaper down the road.
    >
    > Yeah a full install is great: until your broken into. Then you start
    > wishing you'd done some preperation and ran a cleaner filesystem.
    > Organization creates clarity, clarity reduces response time in
    > emergencies. It is that simple.

    Yes I think most would agree that a system should not have extraneous
    applications or packages. I have a couple of single task machines that
    don't have X, or any of the other desktop packages. Everything on the
    machine is tailored to the single task the machine is performing. It is
    much easier to maintain, secure, and monitor. Things like tripwire run
    much faster on a simple system.

    Good luck

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

  4. Re: Cleaning out unneeded executables

    "shrike@cyberspace.org" (06-08-14 14:02:38):

    > Thanks to those who actually attempted to help!


    You're welcome. I hope, we were helpful.


    > The box is locked down to my satisfaction finally. The question posted
    > involved perhaps 1% of the the security policy that was actually
    > involved, but a disproportionate amount of time was required to deal
    > with it.


    This is very true. As I've already pointed out: Security holes are
    elsewhere. The executable files on your filesystems should be your
    smallest security problem. However, what you have said is true also:

    > I would like to point out to any future readers, that running tight
    > machine _is_ helpfull to security if _only_ for the fact that it makes
    > filesystem auditing faster and cheaper down the road.



    > I was truly amazed at the number of posts to this thread that were
    > malicious, negligent, or pointless.


    This is not usual here. I was amazed, too.


    > Yeah a full install is great: until your broken into. Then you start
    > wishing you'd done some preperation and ran a cleaner filesystem.
    > Organization creates clarity, clarity reduces response time in
    > emergencies. It is that simple.


    Well, as soon as your box is compromised, you cannot trust it anymore at
    all. Everything may be manipulated: executables, configurations, the
    kernel, etc. One should rather think about how to prevent this
    scenario, instead of how to recover a system already broken into.


    > Cluefullness !~ Complexity


    On the other hand, cluefullness often leads to a very common pitfall:
    security by obscurity. We all don't like it, but unfortunately many
    people consider this method.


    Regards,
    E.S.

  5. Re: Cleaning out unneeded executables

    On Sun, 06 Aug 2006 19:00:04 -0700, shrike 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?
    >


    Well, the only way to do that is not to put them there in the first place.
    Amany of these apps are there to help during the installation and
    managemnt of other apps.

    So build a crosstool chain, and install only the binaries you need on your
    target system. Put all the 'helper' apps into their own directory
    outside the target. I bet you can get down to just a handful of
    executables that you really need.

    What is really needed is a cross-Gentoo.... :-) Takers, anyone?

    --Yan


    --
    o__
    ,>/'_ o__
    (_)\(_) ,>/'_ o__
    Yan Seiner, PE (_)\(_) ,>/'_ o__
    Certified Personal Trainer (_)\(_) ,>/'_ o__
    Licensed Professional Engineer (_)\(_) ,>/'_
    Who says engineers have to be pencil necked geeks? (_)\(_)


  6. Re: Cleaning out unneeded executables


    Captain Dondo wrote:
    > On Sun, 06 Aug 2006 19:00:04 -0700, shrike 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?
    > >

    >
    > Well, the only way to do that is not to put them there in the first place.
    > Amany of these apps are there to help during the installation and
    > managemnt of other apps.
    >
    > So build a crosstool chain, and install only the binaries you need on your
    > target system. Put all the 'helper' apps into their own directory
    > outside the target. I bet you can get down to just a handful of
    > executables that you really need.
    >
    > What is really needed is a cross-Gentoo.... :-) Takers, anyone?
    >
    > --Yan
    >


    I am down to a handfull of stock files plus the stuff I've written.
    What is a "crosstool" chain? Are you talking about authentication
    between pipes?

    IMHO what is really needed is security down at the malloc() and
    hardware level.

    I'm suprised somebody like Sun or AMD haven't gone completely back to
    the drawing board and come up with a parallel processing architecture
    optimized for security.

    Why do interprocess security in the kernel if you can run each process
    on isolated hardware and stick an ASIC between them to do
    authentication? Then you'd be able to ACL every PID.

    -Matt


  7. Re: Cleaning out unneeded executables

    "shrike@cyberspace.org" (06-08-16 12:12:12):

    > IMHO what is really needed is security down at the malloc() and
    > hardware level.


    What do you mean by security at the malloc() level? What additional
    security features could you add there? Protecting malloc()ed memory
    from other processes and disabling code execution should be already
    about everything possible at this place.


    > I'm suprised somebody like Sun or AMD haven't gone completely back to
    > the drawing board and come up with a parallel processing architecture
    > optimized for security.


    Well, that's a matter of view. IMO, the hardware should be as simple as
    possible, and the software should provide security instead. The
    hardware should only provide, what is needed for the software to
    actually _enforce_ security policies.

    If it were the other way round: How would you handle a hardware bug?
    Buying new hardware? Correcting the hardware yourself?


    > Why do interprocess security in the kernel if you can run each process
    > on isolated hardware and stick an ASIC between them to do
    > authentication? Then you'd be able to ACL every PID.


    Because different operating systems use different security models. You
    would be limited to the facilities provided by the hardware.


    Regards,
    E.S.

  8. Re: Cleaning out unneeded executables

    shrike@cyberspace.org wrote:
    > Captain Dondo wrote:
    >> On Sun, 06 Aug 2006 19:00:04 -0700, shrike 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?
    >>>

    >> Well, the only way to do that is not to put them there in the first place.
    >> Amany of these apps are there to help during the installation and
    >> managemnt of other apps.
    >>
    >> So build a crosstool chain, and install only the binaries you need on your
    >> target system. Put all the 'helper' apps into their own directory
    >> outside the target. I bet you can get down to just a handful of
    >> executables that you really need.
    >>
    >> What is really needed is a cross-Gentoo.... :-) Takers, anyone?
    >>
    >> --Yan
    >>

    >
    > I am down to a handfull of stock files plus the stuff I've written.
    > What is a "crosstool" chain? Are you talking about authentication
    > between pipes?
    >


    kegel.com/crosstool

    It's a way to build the necessary compilers and libs to build your own
    system. It it typically used to build on one archicture (like an x86
    PC) for another architecture (like an ARM SBC).

    But it can also be used to build an x86-compatible environment where you
    control what goes in there. So it is possible to build a completely
    fully functioning glibc-based system in about 32 meg; if you use uClibc
    and text only you can actually get down to about 4MB.

    So you build the basic compilers and libs, then you build busybox, and
    you can boot a shell.

    There is no way you can get there by cutting down a full-blown distro;
    bash alone is 600K while all of busybox is between 200 and 300K, and
    provides *all* of the basic OS functionality.

    --Yan

  9. Re: Cleaning out unneeded executables


    Ertugrul Soeylemez wrote:
    > "shrike@cyberspace.org" (06-08-16 12:12:12):
    >
    > > IMHO what is really needed is security down at the malloc() and
    > > hardware level.

    >
    > What do you mean by security at the malloc() level? What additional
    > security features could you add there? Protecting malloc()ed memory
    > from other processes and disabling code execution should be already
    > about everything possible at this place.
    >


    Doing memory allocation in hardware would prevent kernel hacks from
    hiding things. If you could get a a picture of the memory allocated to
    processes from hardware, then you could have a reliable means of
    checking for rogue processes. People could mess with the Kernel all
    they wanted, but if I can upload a binary that can query the bus and
    thereby the memory allocation table directly, then I have a reliable
    and simple way for checking whether a system is compromised.

    >
    > > I'm suprised somebody like Sun or AMD haven't gone completely back to
    > > the drawing board and come up with a parallel processing architecture
    > > optimized for security.

    >
    > Well, that's a matter of view. IMO, the hardware should be as simple as
    > possible, and the software should provide security instead. The
    > hardware should only provide, what is needed for the software to
    > actually _enforce_ security policies.


    On a typical linux box how many indevidual processes need the full
    processing power of the CPU? If you had say 50 x 40Mhz chips side by
    side each with physically independent block of memory, then you could
    run 50 processes on indevidual chips.

    You have an ASIC on the bus that provides piping between processes.
    That ASIC would allow you to explicitly restrict certain processes
    from network communication or from chaining to any process connected to
    a socket. So you could impliment policies like: kernel modules are only
    loadable from a process connected to the console port.

    >
    > If it were the other way round: How would you handle a hardware bug?
    > Buying new hardware? Correcting the hardware yourself?
    >


    Buy new! Sure! I could see a PC that is basically a bunch of thumb
    drives snapped into a backplane. Each drive is a PC-on-a-chip. The
    backplane is a bus with inter-slot authentication. Essentially you've
    got a cluster of 50 DOS boxes, with a central OS primarily functioning
    to allocate time on the network interface cards.

    Your security policy chips could also be replacable in a similar
    fashion, allowing new feature revisions etc.

    Of course this might suck for certain applications, but you could see
    the vendors making Game versions of the processor modules for
    excellerated graphics etc.

    I'd rather swap a card than recompile and test a kernel.

    >
    > > Why do interprocess security in the kernel if you can run each process
    > > on isolated hardware and stick an ASIC between them to do
    > > authentication? Then you'd be able to ACL every PID.

    >
    > Because different operating systems use different security models. You
    > would be limited to the facilities provided by the hardware.
    >
    >
    > Regards,
    > E.S.


    Yes, different OS's use different security architectures, but I'm not
    confident that that would prevent low level security features available
    in hardware from benefiting any or all of them. To take full advantage
    would probably require completely redesigning the kernel, while limited
    advantage could be achieved by simply writing a driver. Sortof a
    chroot() that is managed by hardware.

    Dunno. It was just a thought.
    Psy


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2