Its rather simple to keep a clean install of any puppy / image based save file.

When you install puppy to flash or hdd, etc. after you save your pup reboot in pfix=ram
Save a copy of your save file and name it backup1 or what ever. Then as you play around with the os save all your documents outside the pup save. Then when you find another chunk of software you like and want to add or keep go back and add your pup save backup file to the boot DIR and boot from it and and the new software and then back that up like you did at the start. Its also good to have a backup of your pup save file encase of a failure.

I respect all that each has reported on viruses, here. But this is about LH64 versus in-depth virus discussion. And, thus far, I am not aware of any reports where LH64 has been influenced by malware.

In the old days, malware commonly exposed itself and was easy to find. Some people have always comforted themselves with the idea that if malware did not jump up and hit them in the nose, it obviously did not exist. That was false reasoning then, and particularly false now. Not finding something is not the same as it not existing.

Modern bot malware often hides until a banking transaction is noticed and then exploited. Rootkits often prevent the file system from seeing malware files, and even return the original contents for changed files. Modern scanning software is essentially useless because polyphonic malware commonly "encrypts" itself under a local key. In general, other than in explicitly instrumented systems, no tool or set of tools exists which can guarantee to find malware. That means anybody can have malware and not know, and we only need look to Microsoft Windows users to see that effect in action.

In the old days, malware was typically differentiated as viruses, or worms, or trojans by delivery path, but nowadays those terms are generally more deceptive than useful. Modern malware can and often does embody all these forms and more in a single attack package, so then what do we call it? We now call it malware.

All of security involves predicting potential problems, and then solving them, hopefully before they are costly. Which of course ideally means *before* the problems are exploited in the wild or ever noticed. Waiting until *after* security problems are noticed, as Microsoft has done, is no success at all. Nobody should encourage doing that.

Malware is not generally a Linux problem, but the reason it is not is not because Linux is better designed or has fewer errors. The reason Linux has less malware is that malware writers make less money from code designed to execute in Linux. The popularity of Microsoft Windows thus makes Linux less risky. However, *less* is not the same as *zero*. Those who seek computing security beyond that provided by the Microsoft combine should be welcomed in the mix which is Linux.

gcmartin wrote:

Hope the link is met with understanding. And, it offers a wider appeal to getting answers-views at that thread than we would get here on this thread.

Understanding? Not so much.

The discussion on this thread was directly related to the Lighthouse64 issues and bugs which I reported, Some of these, related to DVD-load operation, were deflected or dismissed with the observation that a frugal install on a USB flash drive would make more sense. Since I do not agree, I chose to address that claim by discussing the issues which make a flash install less than ideal, thus presenting DVD-boot as the superior solution. That obviously makes *this* the correct place to discuss those issues. *This* is the place for developing those views through discussion and argument, for those who wish to do so.

Anyone who would prefer to talk about something else, somewhere else, should do so. Anyone seeing useless comments here should feel free to skip them. Anyone who considers this discussion worthwhile might link to it from other threads. But nobody should try to impose on others what to discuss or where to do that.

Hope the link is met with understanding. And, it offers a wider appeal to getting answers-views at that thread than we would get here on this thread.

I actually was considering starting a new thread tonight when I got home from work after I saw the conversation continuing, but since RandSec has pretty much stated he wants to comment here, I'll keep it here until TazOC requests otherwise. (it is his thread afterall, and honestly I would like his input on a few things)

RandSec wrote:

I indeed do have both a USB flash with write-enable switch, and a USB card reader which I use with SD cards which have "switches." Neither is satisfactory for malware security.

Can you provide any more information other than 'Neither is satisfactory for malware security.'? I've never heard anyone else say this, so I'm wondering what logic is behind your opinion.

RandSec wrote:

It seems to me that Puppy actually does insist that a flash boot-drive NOT BE REMOVED. (This would be a case of, as TaZoC would say: "It isn't designed, I think to do what you have in mind...") For the case where we boot from a flash drive which really is write-disabled, we CAN, nevertheless, expect to remove the drive without file structure damage, and I have in fact done this. So far so good, but that also means there is no saving to the Puppy save file, and no updates.

There IS the a way to update the system. You simply reboot offline with write-enabled drive, remaster the L64-514.sfs file with whatever programs/setting then reboot with write-disabled. Seriously how often are you adding new programs to your system? For the most part arent most peoples systems stagnant as far as programs and only change with personal documents and program temp files. Yes that may be a bit of work, but if rebooting a system is to much work to securely install a new program, then clearly convenience is more important than security.

RandSec wrote:

The reason we demand a boot flash write-enable is to handle the case of malware having entered during the session and running in memory. We have no particular reason to imagine that we could detect such a thing. So the problem is that we wish to protect our secure non-volatile store from infection. We do that with a write-enable switch. But as soon as we flip that switch for whatever reason, all our security bets are off.

I dont see why you would want/need to write to the drive in the first place other than to install something new.

RandSec wrote:

As soon as we flip the write-enable switch, the flash drive becomes a hard drive equivalent, and can be infected just like a hard drive. Amidst thousands of tiny data-write LED flashes, there is no way to distinguish a few malware infection operations. Nor is there anything about the resulting data which necessarily imply infection. We do not collect a list of changes made to storage, but only the results, and malware hides amidst a deluge of insignificant change.

There aren't thousands of tiny writes when using a frugal install that runs in ram. The only writes to the drive occur when you are saving the session. This can be triggered by a user or allowed to run at a certain interval. I have my intervaal set so that it never runs unless I either trigger it or shutdown. I COULD also take the extra step in setting my boot usb device to read only and modify the save script to save to another media device so that I can 'check' the saved data before integration into my L64-514.sfs file. Plus, I can do that also by simply looking in /initrd/pup_rw/ to see whats there, to see what may be written during save session action. If I dont see something I like, I can simply remove it and its not written.
ANY changes to the live system are saved there before being written into the 2fs, 3fs, 4fs save file. So any user can quickly check to see what 'possible' naughty information is there before doing so. And before someone says that the usb may be written to other than the save file. On a Frugral there are only a dozen files on the drive. If we are talking about a piece of malware being able to infect one of those, then we are WAY beyond a normal malware infection and are at the point of an APT (pardon the buzzword). A piece of malware on that level would have needed to be custom crafted not only explictly for puppy, but for frugral installs within puppy. And even if someone did do that, I think the massive processor spike as a phantom script rebuilds an SFS file on my system would be more than obvious that something is going on that it shouldnt be.

RandSec wrote:

In contrast, a DVD update "session" appears as a separate directory, and all changes are distinguished and encapsulated there. Any malware infection will be there, and that session can be invalidated.

Now TazOC will have to weigh in on this to answer this question, but I dont believe the mechnism for DVD save sessions is all that different from USB frugal save sessions. I dont believe they are, but he'd know more about the process. The USB save session takes all changes to the ram system which are held in /initrd/pup_rw/ and writes them into the save file. I dont see how this is any different than creating a save file on a DVD to load on the next boot. Furthermore as you have already admitted that regarding malware infection, "We have no particular reason to imagine that we could detect such a thing.". What good is good does encapsulation do if you're not going to step through every change on your system at every save? And if you are going to that extent, why not just custom build your own system the way you want. It seems, in my head at least, to as you say 'prize security'; kinda backwards to use someone elses system that you have not personally compilied and assembled yourself. I'm not implying TazOC is not trustworthy, because i truly believe he is; but if you are using a system you have not built, you have no idea what may already be lying in the system, which renders all your efforts pointless.

RandSec wrote:

It seems to me that "keeping changes" really means "possibly keeping malware." Nothing which executes, or is even potentially executable, can be saved with security, if malware is active. And there is no way to know when malware is active, *unless* one has just done a reboot from non-writable (or difficult-write) store, with simple program updates from trusted sources. A Puppy save file would seem to have limited application in that context.

If you're going to take that outlook though, you should NEVER save any information. You could custom build your system with the programs you want and the settings you desire and run that. That system could be run on a read only flash drive, because you wouldnt ever want to save a session. In the off chance you wanted to change your system you could simply remaster your main SFS file to include whatever program you want to add.

RandSec wrote:

It seems to me that once we get past issues of speed and size, the supposed advantage is an assumed ability to erase the flash. That was possible with old-style flash controllers which did not have to balance usage for multi-level analog storage. Yes, flashies can seem to be erased, but internally the information may not be, and it may be recoverable. So erasing a flash may not be as good as it sounds. At least one can break a DVD.

My comments with that had nothing to do with malware, it was forensic based. And there are methods which can be employed to ensure "specific" bits on a flash drive are overwritten EVEN when with a load leveling system on chip level. They are obtuse, but effective; and it works even for large files themselves. And if we are speaking about forensics... breaking a DVD will do nothing, all the data is still readable. If the Air Force OSI can rebuild a hard drive platter after it was removed from a drive and smashed into tiny pieces with a hammer, I'm sure a broken DVD is no problem at all.

RandSec wrote:

Some of these, related to DVD-load operation, were deflected or dismissed with the observation that a frugal install on a USB flash drive would make more sense. Since I do not agree, I chose to address that claim by discussing the issues which make a flash install less than ideal, thus presenting DVD-boot as the superior solution

I was not deflecting or dismissing your issue with the DVD, I simply did not understand your reasoning for doing so. Asking a question about your chosen avenue of security != dismissing it.
It seems your reasons for feeling DVD > Flash centers around the idle write which you feel would occur on a flash based system. While I have no believe I will ever change your mind on this, I do feel its an issue worth discussing openly so that others may read both of our opinions and come to their own personal conclusions on which they feel is superior._________________

RandSec,
Does using the full path /dev/sr0 Burner device: setting work for you in Pburn? I recommend applying that in File -> Preferences -> Burner device -> Save, and then closing and restarting Pburn to make it persistent. You should see

Code:

export BURNDEV=/dev/sr0

in /root/.pburn/pburnrc. That setting is important as it specifies which device is your burner. If you'd like to delve into this further, please visit the Pburn thread. I have made a note to update to the latest version. It could be that other Pups might sometimes allow just sr0, but not currently in Lighthouse64.

Quote:

In contrast, a DVD update "session" appears as a separate directory, and all changes are distinguished and encapsulated there. Any malware infection will be there, and that session can be invalidated.

I agree, the folders on the DVD are each named according to the date each session was saved and can be skipped from loading with the boot option

Code:

pfix=<n> Number of saved sessions to ignore (multisession-CD/DVD)

While I value the ideas and opinions expressed, I agree with Gcmartin that the detailed malware/security-themed discussion is getting off-topic, so please use an appropriate thread.

While I value the ideas and opinions expressed, I agree with Gcmartin that the detailed malware/security-themed discussion is getting off-topic, so please use an appropriate thread.

Thank you,
TaZoC

As requested, when i get home from work ill make a new thread.

With regards to LHP are the mechinisms you have in place for a dvd session save much different from a frugal install save?
from my understanding the only difference is dvd saves each session in a different folder compared to the single save file._________________

With regards to LHP are the mechinisms you have in place for a dvd session save much different from a frugal install save?
from my understanding the only difference is dvd saves each session in a different folder compared to the single save file.

I think the two pupmodes are very different. About the only things they have in common is that they both are Lighthouse / Puppy, and both can save a session.

In PUPMODE 77, saving is only done back to the CD/DVD, and only when you click the Save button, or if you choose yes when asked at shutdown. The session folders each contain individual files, not all combined into one save file. If the power is interrupted, all changed and new files since the last save are lost forever! Unless of course, you intentionally saved or copied them to another media.

Boot up again only uses the DVD, loading each session folder in reverse order, newest first, copying both system files, session files and extra SFS to RAM. Because everything must be copied to RAM from the optical media, boot up can be very slow! Extra SFS can be either in the top level of the DVD or (I think) in a session folder. If a file already exists, the copy only updates files if newer. I experienced a situation where some of the writable files copied from the DVD were coming in read-only, so in L64 all changed and new files except /etc/sudoers are made user writable in RAM. Not the best solution, but it solved the problems I experienced.

So, when you boot Puppy, if tracks are read in reverse order and the latest version of each file copied to your home directory in the ramdisk, what about deleted files? Say you delete a file during one session, that has previously been saved to DVD at the last session, won't it come back again next time you boot? No, Puppy has a mechanism that keeps track of deleted files and this won't happen. However, that does raise an interesting point ... the deleted file is still on the DVD, meaning that every single file that ever existed will be recorded on the DVD, meaning that you have a perfect audit trail of past activity.

Quote:

If you insert a new blank DVD at shutdown, Puppy will burn the complete Puppy system onto the DVD as well as the session -- real handy if the current DVD is getting a bit "iffy".

Boot up again only uses the DVD, loading each session folder in reverse order, newest first, copying both system files, session files and extra SFS to RAM. Because everything must be copied to RAM from the optical media, boot up can be very slow! Extra SFS can be either in the top level of the DVD or (I think) in a session folder.

3 things

Bootup is a CD/DVD/BluRay device speeds...not HDD speeds. But, I boot my 64bit laptop of a regular basis using the DVD. Takes a little more than a minute and a half including save-sessions. On my desktop, its been so long since I rebooted, I cannot remember having booting or what the time was.

I have done 2 different things with LH64. On my laptop, I had used (and reported) a GROWISOFS command to add an SFS in a session prior to version 514. On my desktop, I had used ISOmaster (included OOTB in LH64) where I added an SFS and it was made into the ISO. Both methods worked when booting LH64 DVDs.

Hope this helps_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

Updated DrivesManager 1.5, (thanks to Radky and Jim1911 for testing) and the original Pmount-puppy. Either can be launched from the Filesystem Menu, after the package manager has finished. If you have a UDF DVD created in Windows, please see if DrivesManager can mount it now. Mounting a UDF disc from the desktop icon will not work yet, unless it is first mounted from within DrivesManager. The optical drive desktop icon volume labels will now update when X is restarted.

Funny thing happened with your update..... It broke the LHpup virtual servers.The message dialog came up saying hey there is a new update for LightHouse and a force to the update manager and I found the Backup LHPUP mirror Virtualbox and my puppytune Virtualbox servers not responding to a ping from the network, router, my pc, or the actual server box there on. Though there status showed up good.

Rebooted and ignored the update and the mirror server is up and running again.

I would have caught it sooner but I was over at my neighbors house fixing his old Windows XP computer. I told him "that's it your getting Linuxed." Hes now running LHpup 64 and happy. only thing neg he said was when it first booted and barked at him he stated.."as long as this thing does not get flees were good"

Man you are on top of thigs... I was just about to come post this and ask you if anything special needed to be done to compile it... and here I find you've already gone and done it.
You are freaking awesome!_________________

I am so happy to see you back. It was Lighthouse that won me away from windows.
I have checked back from time to time, I think I even thought I saw a message from you once,
I thought I had dreamed it. Now I know it's for real.

You asked earlier about using Fatdog's Audio-all-in-one-sfs on Lighthouse
My brother and I got it working beautifully in Lighthouse. If what we did, can be of any assistance
to you please let me know.

I have been using Lighthouse for about four years. One of the things I like so much about LHP is,
you put things in places that were logical to me. I am not a geek, but I looked like one using your work
I also appreciated your personal help in the early days when I could not figure out how to do something,
you kindly made work-a-rounds for me.

Would you please verify that the link provided here to donate funds to you,
is legitimate? I am most willing to contribute.

For a mirror site you might want to contact www.smokey01.com
He has a place on his site for puppy developers.
You can see it here http://www.smokey01.com/devs/

Thank your for the kind sentiments and feedback! Yes, the orange Donate button at lhpup.org -> Tips -> top of page, or bottom of some other pages, allows sending of any amount to me. You can use PayPal or a credit card. If you prefer send a check to me, PM me for the mailing address. I plan to set up a new donations page with my costs, donations YTD, etc. and then link to PayPal from there. I have received a total of $66 from 5 contributors year-to-date. I try to acknowledge donations in a timely fashion via PM or email and very much appreciate each one, regardless of the amount. I realize these difficult economic times limit our budgets.

My health is not 100% but am able to get something done most days. I am working toward a release candidate ISO of Lighthouse64, with some bug fixes and a few new packages.

I am trying to improve language support in L64, but most apps are still en_US only, with the exception of the separate LibreOffice and KDE NLS sfs files. I think Opera and Google-chrome are also localized. Drives Manager and Personalize Settings include partial localization. The next release will include GKrellM and Geany, each with full language support. BarryK, 01micko, Shinobar and others are making great strides in this area and I will try to incorporate their work as time allows.