From cfleming@pressroom.com Tue Dec 5 20:43:23 2000 Date: Tue, 5 Dec 2000 15:43:23 -0500 From: Charles M. Fleming cfleming@pressroom.com Subject: [NASSLUG] Text of Blue Sky Discussion Reply-To:=20 The following is the text of my presentation which I will deliver at the Bl= ue Sky Discussion. Please give me your comments especially if you see something that is not right. Thank you, Mike Blue Sky Discussion=20 Charles M. Fleming National Agricultural Statistics Service, Washington= , D.C. 20250 =20 Good morning. I am pleased to join this Second Blue Sky Discussion and to h= ave a part in leading it. Its theme can be traced to the continued climb in= popularity of the Linux operating system, and as result the theme was sele= cted in order to bring about a discussion of how Linux can be utilized in N= ASS. To the best of my knowledge, Linux was first introduced into NASS in Octobe= r 1994 when Jim Burt requisitioned a Slackware distribution of Linux. It to= ok awhile to learn how to install Linux and, especially, to make the xterm = window system work. Nonetheless, after a successful initial installation, t= hanks to Jim's efforts, I have been using Linux as my primary platform for = six years. My little 486 which I inherited from Jeff Bailey is more versati= le and reliable than any Pentium computer I know which runs on Windows. At = first, I examined Linux to satisfy my curiosity and need to find a stable= computational environment. It had become a daily practice to reboot my PC = several times in the morning and several times in the afternoon, so somethi= ng better than Windows had to be found. Now I depend on Linux for the immen= se storehouse of utilities which it makes available to me for doing my math= ematical and statistical work. =20 It has co-incidentally provided me with an extremely fertile ground in whi= ch to learn about the many facets of computer science which would otherwise= remain mysterious if I had been restricted to use only a Windows system. L= inux offers opportunities to experiment with new products which typically c= ome well developed and ready to use even in a early stage of development. R= and LaTeX are two good examples of such packages which I now regard as in= dispensable. B Since the lineage of Linux is UNIX, its strength excels in the task of netw= orking computers peer-to-peer. Not surprisingly, a PC having Linux installe= d on it can serve Microsoft Windows and NT software for an entire network t= ransparently to the individual users of the software at a considerable savi= ngs in management for the network administrator. Being a part of the UNIX w= orld, many utilities from the free software community embellished and great= ly improved the UNIX system in Research Division. For example, my 486 PC wa= s rigged to shutdown seven SUN computers, if there was an extensive power f= ailure. Moreover, John Hoge and Leo Zeggert have developed some very impres= sive systems for NASS which are based on Linux. Indeed, provisions for erec= ting a firewall come natively with Linux; fully functional web server and a= nonymous FTP capabilities that come with Linux are the same ones employed b= y the largest sites on the Internet; such systems as secure shell make it p= ossible to protect confidential information in an encrypted file system. Th= us, reaping the culmination of over 30 years of UNIX development helps to e= xplain the success of Linux in becoming a remarkably robust operating syste= m and has essentially become the most up-to-date and widespread version of = UNIX anywhere. Its success can be attributed to the remarkable management of its developme= nt from all corners of the world. By being copyrighted under the terms of t= he General Public License (GPL) which the Free Software Foundation develope= d and champions, the source code of Linux must be made freely available to = anyone. Consequently, anyone can determine how Linux executes a function an= d more importantly the source code can be modified to accommodate a special= need. If the improvement is deemed a good one, it can be submitted to the = Linux community for general implementation. This collaboration among tens o= f thousands of Linux beta testers and contributors has created a developmen= t team of unsurpassed size and talent. As Jim Burt is fond of saying: "Linu= x is International UNIX". Companies like HP, SCO, and SGI have already stop= ped developing their versions of UNIX. Eventually, IBM's Monterey operating= system will be replaced with Linux. Indeed, IBM is actively developing Lin= ux as you already know. I should note that BSD, Free BSD, Net BSD, and HUR= D are in the same camp as Linux in that their source codes are open, in fac= t, you can find features taken wholesale from BSD and put into a Linux dis= tribution.=20 The free cost of Linux is immaterial; rather, its extreme versatility and r= eliability are its main attractions. It is almost an axiom that there is a = way in the Linux world given sufficient ingenuity to overcome a problem. If= I cannot solve a problem, then someone in a Linux Users' Group will come t= o the rescue. That is why, we recently formed a NASS Linux Users' Group whi= ch we call NASSLUG with its own web page and more importantly a mailing lis= t in order to provide a medium through which communications can take place = among Linux users, UNIX users, or anyone else in NASS who has a curiosity = about open source utilities.=20 In order to generate ideas and to assess potential uses of Linux in NASS , = Phil is sponsoring this Blue Sky Discussion.He should be commended for givi= ng us this opportunity to discuss Linux in the company of so many computer = experts from ITD. =20 Phil asked me to lead this discussion to-day and in leading it I will follo= w the rule of recognizing someone when you raise your hand. Please raise y= our hand when you would like to say something, and I will then recognize yo= u so that you may have the floor. Those joining us via the telephone may sa= y something at any time.=20 We will hear Jim Burt, Jason Frederick, and Leo Zeggert talk about some thi= ng associated with Linux which, I am sure, will interest all of us. After = each presentation, I will open the floor to a discussion. The last round, a= fter Leo's talk, can be about any topic regarding Linux. From cfleming@pressroom.com Thu Dec 7 13:35:07 2000 Date: Thu, 7 Dec 2000 08:35:07 -0500 From: Charles M. Fleming cfleming@pressroom.com Subject: [NASSLUG] Blue Sky Discussion Reply-To: I want to thank everyone for giving me comments about my Blue Sky Discussion presentation. I'll see you on Dec 15th. Mike From cfleming@pressroom.com Fri Dec 8 18:52:47 2000 Date: Fri, 08 Dec 2000 13:52:47 -0500 From: cfleming@pressroom.com cfleming@pressroom.com Subject: [NASSLUG] Tripwire Jim, What are you using in place of Tripwire? You are using a combination of immutable and something else to prevent any surreptitious changes to a file. What is that something else? Mike From jameson@coost.com Sat Dec 9 04:44:21 2000 Date: Fri, 08 Dec 2000 23:44:21 -0500 From: Jameson C. Burt jameson@coost.com Subject: [NASSLUG] Tripwire I use the package/program Aide, which like tripwire makes fancy checksums of every file in a requested list. It does what tripwire did plus, I understand, more. It can, at your option, check for changes in permissions, inode, number of links, user who owns, group who owns, size, modify time, access time, change time, only-growing in size, and a checksum (md5, sha1, rmd160, tiger or all). In different directories, I check different attributes; eg, in /var some files should only increase in size, but their modify time will of coarse change. A couple years ago I ran tripwire on all of many directories, including a 411MB /usr/lib, so tripwire took 1 hour; I have since removed a few large, not crucial, subdirectories from (my now Aide) configuration, so Aide now takes but 3 minutes to gather information on all files my configuration requests. You can see my /etc/aide/aide.conf file in http://www.nasslug.org/somefiles/aide.conf You had properly observed a relation between tripwire/Aide and immutability. I used my Aide configuration, then mostly excluded a few more files, to form my own script looping on "chattr". Concerning your question about immutable files, I use chattr +i filename #applied to many files lcap CAP_LINUX_IMMUTABLE the latter, thru a live kernel modification, preventing any "chattr" changes back until rebooting. I run a hand-made command to do all this, which I call /home/jameson/bin/chattr-security.jameson You can see this file in http://www.nasslug.org/somefiles/chattr-security.jameson-bin I have this script set to ask yes/NO with a 10 second timeout towards the script's end, for which yes would prevent changing immutability back until rebooting. If your boot script always ran "lcap CAP_LINUX_IMMUTABLE" on booting, you could never change numerous files ---so you would eventually want to undo this by something like a boot off CD, mounting your disk's filesystem with /etc/init.d/*, and there altering your boot script with "chattr". If you run such a boot script, you must be careful to prevent odd errors on booting. I had made /etc and a few of its files immutable, but little known to me, booting needed to temporarily create files like /etc/mtab~23. Since the inode /etc was immutable I got booting errors I had never seen, so I had to "chattr -i /etc" and reboot. While largely unimportant and uninteresting, I run this script through Linux's init system on bootup/shutdown, via the file /etc/init.d/chattr-security.jameson which I put (for your viewing) in http://www.nasslug.org/somefiles/chattr-security.jameson The magical part is what I had never seen before on any computer system, but I now understand is also on BSD unix: lcap. > Jim, > > What are you using in place of Tripwire? You are using a combination of > immutable and something else to prevent any surreptitious changes to a file. > What is that something else? > > Mike > -- Jameson C. Burt, NJ9L Fairfax, Virginia, USA jameson@coost.com http://www.coost.com (202) 690-0380 (work) You can only find truth with logic if you have already found truth without it. -- G.K. Chesterton