ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   18 Feb 2002  13:17:12
 To : All
 Subject : URL: http://www.lwn.net/2002/0214/letters.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] [No ads right now]
    [LWN.net]
 
    Sections:
     [2]Main page
     [3]Security
     [4]Kernel
     [5]Distributions
     [6]Development
     [7]Commerce
     [8]Linux in the news
     [9]Announcements
     Letters
    [10]All in one big page
 
    See also: [11]last week's Letters page.
 
 Letters to the editor
 
    Letters to the editor should be sent to [12]letters@lwn.net.
    Preference will be given to letters which are short, to the point, and
    well written. If you want your email address "anti-spammed" in some
    way please be sure to let us know. We do not have a policy against
    anonymous letters, but we will be reluctant to include them.
    February 14, 2002
 From:    Phil Cameron <pcameron@CrescentNetworks.com>
 To:      letters@lwn.net, pecameron@mediaone.net
 Subject: Security perspective
 Date:    Thu, 07 Feb 2002 12:56:48 -0500
 
 There are a couple of more points to consider when counting the security
 updates.
 1) Is this a fix for a known exploit or is it a fix for something that
 can happen in theory.
 2) What damage can be caused by the exploit?
 
 Looking at this weeks updates:
 Mandrake Linux Security Update - GZIP:
 This fixes two problems with the gzip archiving program; the first is a
 crash when an input file name is over 1020 characters, and the second is
 a buffer overflow that could be exploited if gzip is run on a server
 such as an FTP server.
 
 The first is not security related and the second looks like an exploit
 that can cause damage. Is there a known exploit? A lot of things that
 seem possible turn out to not be possible because of the interaction of
 other software.
 
 Net::FTPServer security fix.
 close a potential vulnerability "allowing users to list directories to
 which they should not have access. If your configuration file uses 'list
 rule', then you need to upgrade to version 1.034."
 
 How bad is this? What actual damage can be done? You can't actually
 "get" the files, just list them. There doesn't seem to be a known
 exploit. Do we count it any way?
 
 PHP Safe Mode Filesystem Circumvention Problem
 "If an attacker has access to a MySQL server [...], he can use it as a
 proxy by which to download files residing on the [PHP] safe_mode-enabled
 web server".
 
 OK how do you count this? Is there a known exploit? What does it take to
 gain access to a MySQL server?
 Much of the time, we see bugs that are uncovered by reviewing code and
 during debugging. Every once in a while a really important vulnerability
 is discovered.  How many of these bugs will actually be seen on
 production machines? I personally like to see these reports because it
 shows that people are taking security seriously and are trying to plug
 holes that could possibly exist. The more we do this the stronger the
 system gets. It is unfair to compare them with other vendors products
 without carefully analyzing the nature of both systems problems.
 
 As for distributions, I would like to see a basic out of the box secure
 system. The entire system needs to operate in the secure mode so that
 the installer or admin does not have a need to weaken it. Secure out of
 the box is value that distributors can add that can distinguish them
 from each other.
 
 Phil Cameron
 From:    Armijn Hemel <armijn@nl.linux.org>
 To:      corbet@lwn.net
 Subject: .NET stuff
 Date:    Thu, 7 Feb 2002 17:06:34 +0100
 
 hello LWN,
 
 with a lot of interest I've been following all this discussion about Mono
 and .NET. One of my former teachers here at the university is now program
 manager of the Common Language Runtime for .NET and I've read a few articles
 and magazines (issued by Microsoft) about this whole .NET thing.
 
 The .NET concept is indeed very nice. There is a good defined bytecode
 language (Intermediate Language, IL), a decent runtime and a set of
 compilers for different languages to compile to IL.
 Sounds neat, because you can then write stuff you want in one language
 and use it in another language. You can specialize in writing the language
 that is best suited for the task.
 
 What most people forget is that to ensure that this can happen there
 is a specification (the Common Type System, CTS) which describes which
 datatypes you can use in a language if you want to take full advantage of
 the .NET framework.
 
 A quote from the Microsoft MSDN site about the CTS:
 
 \begin{quote}
 
 The common type system defines how types are declared, used, and managed in
 the runtime, and is also an important part of the runtime's support for
 cross-language integration. The common type system performs the following
 functions:
 
 * Establishes a framework that enables cross-language integration, type
   safety, and high performance code execution.
 * Provides an object-oriented model that supports the complete implementation
   of many programming languages.
 * Defines rules that languages must follow, which helps ensure that objects
   written in different languages can interact with each other.
 
 \end{quote}
 
 [13]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/ht
 ml/cpconthecommontypesystem.asp
 
 So, while .NET does not limit you in the number of programming languages
 it does limit how these languages are being used (see the third `function' of
 the CTS above), which is (I think) a serious drawback if you want to do real
 programming. Therefor I can't understand why Miguel is so positive about the
 .NET framework...
 
 armijn
 
 --
  ---------------------------------------------------------------------------
    armijn@nl.linux.org | [14]http://people.nl.linux.org/~armijn/ | Penguin Powe
 r
  ---------------------------------------------------------------------------
                  [15]http://nl.linux.org/ | Alles over Linux
  ---------------------------------------------------------------------------
 From:    dps@io.stargate.co.uk
 To:      letters@lwn.net
 Subject: Region coding---the truth vs. what is said
 Date:    Thu, 7 Feb 2002 18:44:36 GMT
 
 I think most people believe the real reason for region coding
 DVDs is that people can charge more for less in europe. The
 studios would deny it but that is probably because saying so
 would leave them liable to unpleasant prosection (under consumer
 protection and free trade statutes). Let it suffice to say the
 same DVD costs a lot less if bought in america... and you
 might get more on the american version too.
 
 I am fairly sure that what was said in court was that DeCSS and
 other efforts that allow people to exervise their fair use rights
 should not be allowed becuase that would allow piracy. The logic
 is a little flimsy, for example I could just record the video
 signal on a good quality video recorder and probably get something
 close to the quality of the DVD, but when did logic get in the way
 of attempting to abuse the law? Legal niceties like terms that are
 legally null and void in licence agreements, because those terms
 are illegal, are still present (the mnost common is the "by openning
 this envelope you agree to these terms" language---legal advice is
 that this has no force in the UK).
 
 Fortunately america can not unilatterally abolish limits to their
 juristiction, and the DMCA does not apply in europe. Even if it
 did extradition to america is dubious because much of europe will
 not allow extradition to anywhere with the death penality (and
 defninitely not if the death penality might be applied).
 
 P.S. As a person with no TV, sound card, or DVD reading equipment
 the obvious DVD practices do not affect me. I am thinking about
 a DVD writer for backing up *my own* data (CDs are just too
 small).
 From:    jimd@starshine.org (Jim Dennis)
 To:      letters@lwn.net
 Subject: chkrootkit and System Integrity Auditing
 Date:    Thu,  7 Feb 2002 16:10:07 -0800 (PST)
 
  Hi,
 
  The fundamental problem with any tool like tripwire, aide,
  chkrootkit, or any other system integrity system (including
  virus scanners under other operating systems) is that they
  MUST BE RUN FROM A KNOWN CLEAN SYSTEM BOOT.
 
  That is the first, foremost, and inescapable rules of
  system integrity auditing.  You must boot from known clean,
  write-protected media.
 
  I realize that this advice rankles sysadmins with an
  uptime fetish.  However, I want to impress people that it
  is almost invariate.  The only scenario I've imagined where
  I *might* accept the integrity of "hot" system audit would
  be in a case where hardware mirroring or raid would allow me
  to randomly pull a set of system volumes, push them into
  a KNOWN CLEAN standby system and perform the audit therefrom.
  I have not yet implemented such a scenario and would only
  recommend it for cases where the server had hard and fast
  uptime requirements that couldn't be met through clustering,
  etc.  (In other words, I might consider that auditing model
  for zSeries and S390 mainframes running 24x7 database
  services).
 
  That said I have to point out the second inviolable law of
  system integrity auditing --- you MUST capture the reference
  data (checksums, permissions, backup copies, whatever)
  BEFORE any exposure.  So, ideally, you install and configure
  the system on a workbench (no network connection), prepare your
  reference data set and then connect the system to your LAN or
  net.
 
  My favorite system integrity reference data is a simple tar
  file.  My favorite system auditing technique is:
 
         boot from LNX-BBC (or tom's root/boot, or ...)
         mount filesystems
         insert reference media (write-protected tape, CD-R, whatever)
         tar dzf /dev/st0 (or whatever)
 
  ... this should detect all difference in content, permissions,
  and some innocuous things like timestamps and squawk about them.
 
  Part of the beauty of this system is that it ensure ready recovery
  from any problems you detect (left as exercise to the student, but
  it might involve replace a 'd' with an 'x').
 
  Of course the principal disadvantage is that you have to also
  manage all those nasty updates.  In practice we really care about
  the core kernel, shell, libc, and system utilities (up to and
  including our gpg, aide, md5sum, and ssh tools).  Then we can
  (after insuring their integrity) reasonably rely on those tools
  for the rest of our tests.
 
  For Debian systems we can use commands like:
 
         ar p $PACKAGE data.tar.gz | tar dzf -
 
  ... to perform a quick and dirty audit of a given package's files
  versus those under our current directory (at the root of the
  distribution's installation, but possibly mounted at an arbitrary
  place because we've booted from BBC/CDR).
 
  On can perform similar tricks using rpm -Vp ... (though that will be
  checking checksums rather than doing a bit-for-bit comparison).
 
  I could give a full day class in system integrity auditing techniques.
  However, these few tips should help.  There are numerous
  alternatives to tripwire/aide (recent versions of tripwire are not
  free).  I recommend installing aide (apt-get-able for Debianistas)
  and one other (more obscure one) like fcheck, viperdb, or maybe a
  custom perl script for redundancy.  Assume that your attacker knows
  about tools like chkrootkit, aide, and tripwire (the big ones)
  so maintain an extra little surprise for the lazy and careless
  cracker to miss.
 
  Having nightly cron job is useful, it will catch the most careless
  and lazy script kiddies.  However, it is wise to assume that your
  cracker will search or compromise your cron subsystem, so squirrel
  your backup alarm triggers into more obscure places such as a
  user's at job (possiblly SUID root, but only executable to their group)
  or perhaps a custom little patch to syslogd, sshd, or some other daemon
  which spawns the check every day (and sends a heart beat to some other
  system to alert it that *that* daemon hasn't been summarily replaced.)
 
  I realize that this all sounds like paranoid spy novel stuff.  But
  it's really silly to underestimate your attackers.
 
  (BTW: any cracker reading this: don't bother attacking my home systems,
  they are uninteresting play toys that are not particularly hardened
  and my link to the net is a pathetic little IDSL.  There's no sport in
  defacing my web pages because I'm not noted enough for the bragging
  rights to mean anything.  I reserve my real work for giving free advice
  and for paying customers).
 
 --
 Jim Dennis,
 Starshine Technical Services
 From:    chris.m.moore@amsjv.com
 To:      john.lettice@theregister.co.uk
 Subject: The comments on the MS Seatlement
 Date:    Tue, 12 Feb 2002 11:35:02 +0000
 Cc:      letters@lwn.net
 
 Hi,
 
 By labelling the comments which only discuss the RPFJ as a starting
 point as "substantive" the DOJ and the Register ("DoJ-MS comments: that
 breakdown in full") have dismissed the vast majority of the comments
 which "express an overall view of the RPFJ [Revised Proposed Final
 Judgment] but do not contain any further discussion of it".
 
 I count the letter I sent in this category (and Hans Reisers too, see
 [16]http://linuxpr.com/releases/4445.html).  I dismissed the current
 settlement as ineffective (the MS stock price rose after it was
 announced) and proposed an alternate solution based on the LGPL (with
 certain restrictions to prevent vertical markets forming).  I suspect
 many of these 19500 comments would start from the premise that the
 current settlement is useless and propose alternatives.
 
 In any battle a general wants to pick the ground on which to fight.  By
 picking the RPFJ, the DOJ and MS hopes to curtail further discussion.
 I'm quietly encouraged that the judge has refused the application for a
 limited oral hearing on this matter.
 
 Chris M. Moore
 Software engineer
 Portsmouth, UK
    [17]Eklektix, Inc. Linux powered! Copyright Л 2002 [18]Eklektix, Inc.,
    all rights reserved
    Linux (R) is a registered trademark of Linus Torvalds
 
 References
 
    1. http://lwn.net/
    2. http://lwn.net/2002/0214/
    3. http://lwn.net/2002/0214/security.php3
    4. http://lwn.net/2002/0214/kernel.php3
    5. http://lwn.net/2002/0214/dists.php3
    6. http://lwn.net/2002/0214/devel.php3
    7. http://lwn.net/2002/0214/commerce.php3
    8. http://lwn.net/2002/0214/press.php3
    9. http://lwn.net/2002/0214/announce.php3
   10. http://lwn.net/2002/0214/bigpage.php3
   11. http://lwn.net/2002/0207/letters.php3
   12. mailto:letters@lwn.net
   13.
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cp
 conthecommontypesystem.asp
   14. http://people.nl.linux.org/~armijn/
   15. http://nl.linux.org/
   16. http://linuxpr.com/releases/4445.html
   17. http://www.eklektix.com/
   18. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор