RE: Installation of software, and security. . .

From: Burton Strauss (
Date: 07/19/05

  • Next message: Dustin D. Trammell: "Re: On classifying attacks"
    To: "'Tim Nelson'" <>, "'John Richard Moser'" <>
    Date: Tue, 19 Jul 2005 12:24:39 -0500

    I think you are wrong. Suppose you do create that (mythical) complete set
    of actions inside the package manager.

    You can't add security - by definition if you run an rpm-type install you
    are root, so there's nothing new.

    You can't use something like SELinux unless you split the package in two (a
    god-equivalent version to add the permissions for the install to the SElinux
    databases and then a non-root install using those permissions). So instead
    of hacking into the install, just hack into the god-equiv part).

    All you've done for yourself is to create another (mini) 'language' the
    packager has to learn, instead of using good ole

    Where there could be gains are in a small number of those 'hard to do right'
    actions, which are usually erroneously scripted. But as it is, many RPMs
    (and I'm guilty here), don't use what IS available. So adding more things
    won't really help that much either.

    Fixing package scripts to take advantage of your new, wonderful actions
    would be a massive task, across 1000s of packages (and egos) to fix.

    So if there's nothing gained, well, why bother?

    However, there is somewhere you can affect things - and that is within rpm
    itself. How: enable/force better logging of the actions performed during a
    script. Down to the line-of-a-script level if you want. That would be
    effective/useful, even if nobody ever fixed up a script.


    -----Original Message-----
    From: Tim Nelson []
    Sent: Monday, July 18, 2005 11:01 PM
    To: John Richard Moser
    Cc: Klaus Schwenk;
    Subject: Re: Installation of software, and security. . .

    On Sun, 17 Jul 2005, John Richard Moser wrote:

    >> like a complete mess. Far too many programs wouldn't need an
    >> installation in the first place. And it's hard to give end users a
    >> rule of thumb on how to handle installation programs when there is no
    >> real agreement on what installers should
    >> (not) do. At least from my POV.
    > Yes, you hit the nail on the head with a jackhammer. One discussion
    > on autopackage was that the devs don't want to limit the API and thus
    > want the prepare, install, and uninstall to be a bash script supplied
    > by the package "so it can do anything." I hate this logic. Why does
    > it need to be able to do "anything"?

             I think you're both right :). I agree that packages need to be able
    to do anything, but it'd be nice if we could try to eliminate the pre and
    post install scripts.

             One thing that would be useful is if someone could look at the
    things that are typically done in pre/post install scripts, and then
    integrate those into the package manager. We have a set of custom RPMs
    here, and they do a variety of things in the pre and post install scripts,
    but the main ones are:
    - Reconfigure other software; apache never needs this, because it
             uses the conf.d directory, but the tomcat we use doesn't seem to
             work this way, and it should
    - Service reloads; after we add a file which does the apache config,
             we need to reload apache; if RPM supported us going
             "%reload apache", then we wouldn't need the post-install script
             for that

             My suggested solution would be to:
    1. Build in to RPM (or whatever) any relatively harmless features
             which are regularly used (eg. reload)
    2. Issue a security warning and quit for any packages that have
             pre/post install scripts, and any actions that might cause trouble
             (eg. reload)
    3. Set --with-scripts (or something) to enable running scripts, and
             --with-actions to enable potentially troublesome actions (eg.
             reload), or --without-actions to just install files and not do the



    Kind Regards,
    Tim Nelson
    Server Administrator
    P: 03 9934 0888
    F: 03 9934 0899
    WebAlive Technologies
    Level 1, Innovation Building
    Digital Harbour
    1010 La Trobe Street
    Docklands Melbourne VIC 3008
    This email (including all attachments) is intended solely for the named
    addressee. It is confidential and may contain legally privileged
    information. If you receive it in error, please let us know by reply email,
    delete it from your system and destroy any copies. This email is also
    subject to copyright. No part of it should be reproduced, adapted or
    transmitted without the written consent of the copyright owner.
    Emails may be interfered with, may contain computer viruses or other defects
    and may not be successfully replicated on other systems. We give no
    warranties in relation to these matters. If you have any doubts about the
    authenticity of an email purportedly sent by us, please contact us

  • Next message: Dustin D. Trammell: "Re: On classifying attacks"

    Relevant Pages

    • Errors applying kernel patch 118833-36
      ... install of Solaris 10 11/06. ... However, once the package list is done, I see a worrisome message: ... Below is the complete console output of the patch run. ... Changes for package SUNWnfsskr will not be applied to the system. ...
    • Re: Debians policy regarding security updates
      ... So from what I gather, once a patched package has moved into sarge, it's ... rather safe to install it to replace the older, vulnerable package, i.e. ... queued up in sid at one time because dependencies hadn't been resolved ... So if the security risk is high and one doesn't want to wait for the ...
    • Re: [ANN] froglogic releases Pq, a Qt implementation of Perl/Tk
      ... "Pq" is rather difficult to compile, install, etc. ... I decided to use perl/TK in my scripts ... make into an standard installable package you have a winner. ... > availability of Pq which is an implementation of the Perl/Tk GUI ...
    • SUSE Security Announcement: openSSL protocol downgrade attack (SUSE-SA:2005:061)
      ... Please install the updated packages. ... Package Location and Checksums ... The preferred method for installing security updates is to use the YaST ... The authenticity and integrity of a SUSE security announcement is ...
    • [Full-disclosure] SUSE Security Announcement: openSSL protocol downgrade attack (SUSE-SA:2005:061)
      ... Please install the updated packages. ... Package Location and Checksums ... The preferred method for installing security updates is to use the YaST ... The authenticity and integrity of a SUSE security announcement is ...