Lighthouse 64 5.14.2 Beta 4

[meeki]

well ive put it through a few paces.

It does not like me to make linux ext2 - 4 drives unless I use the entire drive option.
"device-mapper: reload ioctl failed: No such file or directory
Command failed"

[Anniekin]

subcribing

[Q5sys]

well ive put it through a few paces.

It does not like me to make linux ext2 - 4 drives unless I use the entire drive option.
"device-mapper: reload ioctl failed: No such file or directory
Command failed"

I got that message the first time I loaded it. After a reboot though it went away.

[RandSec]

Hi tazoc!

1. This is an issue I first noticed in 5.12: Pburn fails when commanded to erase a DVD. That means I have to boot a 32-bit Puppy just to erase discs. Here are the error log results from my earlier comment:

(first, selecting a complete blank)
Pburn version 3.3.4

###################################################
COMMAND:
###################################################

growisofs -use-the-force-luke=notray -Z sr0=/dev/zero

###################################################
OUTPUT:
###################################################
:-( "sr0=/dev/zero": unexpected errno:No such file or directory



(next, selecting a fast blank)
Pburn version 3.3.4

###################################################
COMMAND:
###################################################

dvd+rw-format -force sr0

###################################################
OUTPUT:
###################################################
* BD/DVD±RW/-RAM format utility by <appro@fy.chalmers.se>, version 7.1.
- usage: dvd+rw-format [-force[=full]] [-lead-out|-blank[=full]]
[-ssa[=none|default|max|XXXm]] /dev/dvd


2. I operate solely and completely as a LiveDVD. When it comes time to copy a disc (for other computers, or as a backup, or just to reduce the number of sessions which load upon startup) I am used to making another .ISO disc, and then doing a Save to that disc. That works, at least when the ISO is the same. So I am questioning the instruction text which says:

"Please insert the Lighthouse64 live-CD/DVD media that you booted from...."

It should say something like "For a new backup copy of the whole disc, insert a new bare ISO, or to save the current session, insert the Lighthouse64 boot disc."

On the other hand, it should be reasonably easy for the computer to check if the Lighthouse64 media is already there, or is a new ISO, which could avoid having the novice user try to do something when nothing is needed.

I love Lighthouse64, and hope it continues!

[Ted Dog]

growisofs -use-the-force-luke=notray -Z /dev/sr0=/dev/zero

simple typo

[RandSec]

A few days ago our audio-visual Windows PC died in the middle of showing a DVD, apparently a motherboard fail. It was past time to move on anyway. So I have a new box and have been swapping things in and out to get our entertainment back up.

Eventually we will need to get Windows up so we can stream Netflix. But we should be able to play DVD''s with really good video and full surround sound on Linux, and I really, really want a DVD-load format. Lighthouse64 has been by far the best choice, but issues remain:

3. DVD-write Save does not retain Retrovol settings (identifying which channels are active in 5.1 surround is trickier than one might think, because the text labels are deceptive)

4. Switching the Lighthouse64 boot disc out, and a 32-bit Puppy in (to mount and then review the saved directories), confusingly did not change the label text on the desktop DVD icon

5. We need AbiWord to have the available file-import plug-in or import filter to access our old archived WordPerfect files (typically .WPD). What sense does it make, really, to leave any of the import filters out of an editor package?

There was something else which I will no doubt remember as soon as I send this off.

[tazoc]

###################################################
COMMAND:
###################################################

growisofs -use-the-force-luke=notray -Z sr0=/dev/zero

###################################################
OUTPUT:
###################################################
"sr0=/dev/zero": unexpected errno:No such file or directory

Did Ted Dog's fix work there?

(next, selecting a fast blank)
Pburn version 3.3.4

###################################################
COMMAND:
###################################################

dvd+rw-format -force sr0

###################################################
OUTPUT:
###################################################
* BD/DVD±RW/-RAM format utility by <appro@fy.chalmers.se>, version 7.1.
- usage: dvd+rw-format [-force[=full]] [-lead-out|-blank[=full]]
[-ssa[=none|default|max|XXXm]] /dev/dvd

I'm confused here, is that the command Pburn generated or your own? I just use what Pburn gives and usually do a full erase if I recall.

2. I operate solely and completely as a LiveDVD. When it comes time to copy a disc (for other computers, or as a backup, or just to reduce the number of sessions which load upon startup) I am used to making another .ISO disc, and then doing a Save to that disc. That works, at least when the ISO is the same. So I am questioning the instruction text which says:

"Please insert the Lighthouse64 live-CD/DVD media that you booted from...."

It should say something like "For a new backup copy of the whole disc, insert a new bare ISO, or to save the current session, insert the Lighthouse64 boot disc."

On the other hand, it should be reasonably easy for the computer to check if the Lighthouse64 media is already there, or is a new ISO, which could avoid having the novice user try to do something when nothing is needed.

If I'm understanding this situation it is in Multi-Session DVD, the experimental mode and you're saving your current session. BarryK wrote that script, essentially I just changed Puppy to Lighthouse. It will prompt you for a blank disc when the first one is full. It also assumes that the disc may have been replaced during the session and doesn't attempt to mount the current disc until you confirm it is the correct one. It isn't designed, I think to do what you have in mind... Maybe someone else could help with a re-write and testing?

3. DVD-write Save does not retain Retrovol settings (identifying which channels are active in 5.1 surround is trickier than one might think, because the text labels are deceptive)

Is that also true when saving the session at shutdown/reboot, or only from the Save icon on the desktop?

4. Switching the Lighthouse64 boot disc out, and a 32-bit Puppy in (to mount and then review the saved directories), confusingly did not change the label text on the desktop DVD icon

Yes, I've seen that also and am working on a possible fix to clear the blkid cache /var/cache/blkid at X startup. I didn't want to scan the CD/DVDs for a new disc label more often because it makes the drives spin up annoyingly and slows pmount and the desktop down to a crawl.

5. We need AbiWord to have the available file-import plug-in or import filter to access our old archived WordPerfect files (typically .WPD). What sense does it make, really, to leave any of the import filters out of an editor package?

I thought I grabbed everything from Abiword out of Fatdog64 521, but I'll keep that in mind the next go-around. I usually use LibreOffice instead of Abiword.
-TaZoC

[tazoc]

Here is an update for Adobe Flashplayer:
http://www.lhpup.org/update/L64-514/Int ... x86_64.pet

Meeki has generously provided a mirror for the Lighthouse web site, for if and when lhpup.org is unavailable.

http://lhpup.puppytune.org

Thank you Meeki!

-TaZoC

[RandSec]

I'm confused here, is that the command Pburn generated or your own? I just use what Pburn gives and usually do a full erase if I recall.

What you see is what I see, so I was as confused as you. This is the log referenced by Pburn when it returns fail. I assume that Pburn functions by generating commands which are then executed, and when they fail, error messages are logged. Are you saying that when you try to erase a DVD-RW or DVD+RW on your system, failure does not happen?

If I'm understanding this situation it is in Multi-Session DVD, the experimental mode and you're saving your current session.

I have been using multisession mode EXCLUSIVELY for several years, across a range of Puppies. In my experience, the multisession DVD is unique among "LiveDVD" distributions and supports user updates whereas most other LiveDVD distros need the user to download a new .ISO version.

I suppose anything can be "experimental" if someone calls it so, but it seems more likely that, once having written "experimental" in the text, the text remains while the feature soldiers on. Calling any feature "experimental" for years on end seems more than a little contradictory.

BarryK wrote that script, essentially I just changed Puppy to Lighthouse. It will prompt you for a blank disc when the first one is full. It also assumes that the disc may have been replaced during the session and doesn't attempt to mount the current disc until you confirm it is the correct one. It isn't designed, I think to do what you have in mind... Maybe someone else could help with a re-write and testing?

Surely you are in a better position than myself to know what the original purpose of the design might have been. However, I can say how it does operate, and thus wish that the associated text was updated to make it less confusing for the user.

In general, it will be important for the multisession user to make system copies. These are needed for backups, as copies for other users, and for maintenance, to compress an array of sessions into one. In general, this is done by creating a new .ISO disc, and then doing a Save onto that disc. While I do not know the limits of this (e.g., will it work with an updated .ISO?), I do know this to be very important for actual LiveDVD use.

3. DVD-write Save does not retain Retrovol settings (identifying which channels are active in 5.1 surround is trickier than one might think, because the text labels are deceptive)

Is that also true when saving the session at shutdown/reboot, or only from the Save icon on the desktop?

I cannot know, because I do not have a hard drive in my Puppy systems. Only in this way can I have a virtual guarantee against malware infection.

I never do anything other than Save from the desktop (except for the first session, where there is no Save icon), because I have experienced too many disastrous failures when saving at shutdown. The DVD save process occasionally fails, and then the system exits and powers off, despite the data having not saved. When I first started with Puppy, this Save failure was extremely irritating and very discouraging.

The actual problem is not in having an "experimental" system, but instead the nature of optical storage, which does not, and almost cannot, have the read-after-write checks of magnetic drives. A sector in a hard drive can be automatically swapped for another without significant intrusion, but a DVD session write must be repeated completely, which cannot be automatic within the drive without massive drive RAM.

I have learned through hard experience to Save from the desktop when needed, AND to then mount the resulting DVD and look at the directory structure. Usually, the recent Save is apparent, but if not, I Save again. So far, that has always worked, but even if not, it is far, far better to have the system remain up than simply turn off. It is possible to Save the same session multiple times at modest DVD space cost, and with minimal load time effect.

4. Switching the Lighthouse64 boot disc out, and a 32-bit Puppy in (to mount and then review the saved directories), confusingly did not change the label text on the desktop DVD icon

Yes, I've seen that also and am working on a possible fix to clear the blkid cache /var/cache/blkid at X startup. I didn't want to scan the CD/DVDs for a new disc label more often because it makes the drives spin up annoyingly and slows pmount and the desktop down to a crawl.

Surely there must already be something which reads the label and saves it somewhere so it can be displayed upon X restarts, or maybe just re-reads each label upon X restart. Every distro must solve that somehow.

5. We need AbiWord to have the available file-import plug-in or import filter to access our old archived WordPerfect files (typically .WPD). What sense does it make, really, to leave any of the import filters out of an editor package?

I thought I grabbed everything from Abiword out of Fatdog64 521, but I'll keep that in mind the next go-around. I usually use LibreOffice instead of Abiword.
-TaZoC

Fatdog64 may not have all the import filters. Normally, we do not use Abiword, but want it available to access our archived work, and so want the minimum footprint on the DVD (well, compared to LibreOffice). I think this was one of the reasons the wife moved back to 5.2.5 from Lighthouse64, so it is at least that real. I cannot remember if we tried to import .WPD's in LibreOffice or not.

[Q5sys]

RandSec
Is there any reason you are opting to go with DVD media over another form of removable media?
I dont get what security benefit you are getting against 'malware' using a dvd. If you are burning save sessions to a new DVD, then you're not using a read only system... so you are still open to infections.

Is there any benefit you are gaining? Because it seems like you are dealing with a ton of headaches because of it.

[RandSec]

RandSec
Is there any reason you are opting to go with DVD media over another form of removable media?

I think so, yes.

It may or may not help to give some of my background, and there is a lot on my site:

http://www.ciphersbyritter.com

I am basically retired, but even 10 years ago I was C programming as a consultant on embedded systems. For the past couple of decades I have been concentrating on security, first cryptography, and now malware. See my various malware articles at:

http://www.ciphersbyritter.com/COMPSEC/COMPSEC.HTM

Recently I have tried to advise the US Government on Bots:

http://www.nist.gov/itl/upload/Ritter_A ... N-BOTS.pdf

so basically I have some background in this area.

With respect to vulnerable store, the issue is less one of "removable" than it is "writable." Both hard drives and USB flash drives are instantaneously writable. Even in Puppy, these systems involve constant interaction with non-volatile store. In particular, it is common in these systems to access and rewrite disk "sectors," which are tiny fragments of files. These are easily read, modified for infection, and written, all in a fraction of a second. The infection process thus is just one more tiny flash of the activity LED among millions. The failure of indication is the failure of the last line of defense, because there are no tools which guarantee to find a hiding malware infection. Absent non-existent OS support, identifying all code which does bad things is theoretically impossible.

In contrast, a Puppy DVD-load system runs in RAM and DOES NOT ACCESS THE DVD in normal operation. Any malware actions to write the DVD thus become apparent and revealed simply by DVD activity. Since there are no DVD "sectors," infection apparently requires a very substantial effort to create a new DVD "session" (a new directory) on the DVD. And even malware cannot write to a DVD which is not in the slot.

I dont get what security benefit you are getting against 'malware' using a dvd. If you are burning save sessions to a new DVD, then you're not using a read only system... so you are still open to infections.

I guess I would say the difference is that your model of "read-only" vs. "writable" is too simple to capture the reality of the situation. This is, of course, similar to the model of the file system being protected by permission bits, when malware interprets those bits. It is also similar to the model of running as root, when the system is for just a single user anyway. The simple models often are imperfect substitutes for deeper understanding, and we often need to get beyond them.

There is, and can be, no perfect security. All security comparisons are necessarily relative. The usual disk-install Puppy system has a continuous interaction with the hard drive (or USB flash), with continued drive activity flashes, just like Microsoft Windows, and is similarly vulnerable. Malware infection of an intensely-used and easily-writable drive is just one tiny blip among many, which is no indication at all. In contrast, a Puppy DVD-load system has a quiet and dark DVD writer; attempted malware infection lights up what should be dark and so is obvious.

On the other hand, if Puppy would treat a USB flash drive similar to the way it treats a DVD, then we would have something! It would be a much faster load, and THEN WE WOULD REMOVE THE USB! I particularly would appreciate the DVD Save ability to keep multiple versions of files (in different directories), allowing one to go back to earlier article versions. That is what we could have, but it is not what we do have. We are necessarily forced to deal with what we have.

Is there any benefit you are gaining? Because it seems like you are dealing with a ton of headaches because of it.

First of all, I am unsure about this "ton of headaches" meme with respect to DVD-load operation. That certainly was true when I first started with Puppy, now several years ago, and it was very frustrating until I understood some of the problems and found solutions. Fortunately, all operations necessary to make DVD-load a practical mode are in fact available. These are not hard, or "headaches," just hidden. I use it all day, every day.

The benefit is to (*almost* absolutely) prevent infection, which simply cannot be done otherwise in current systems. Even Microsoft Windows 8, which supports or demands UEFI, seems unlikely to address the real problem. A correct response does not need signing or cryptography. The problem is that the current concept of "disk drive" does not include a protected area for the OS, which means that anything which can write to the disk (having first "owned" the OS), at least potentially can infect ALL FUTURE SESSIONS. We seek to prevent this *infection*.

It is important to distinguish *infection* from malware execution: Malware can *run* whenever it somehow gets through the "front end" protections, like router firewall, software firewall, browser, browser security add-on's, etc., or trojan email attachments, or infected USB flash, etc. Because the Web and our equipment was not designed to prevent malware from running, it may run, even in Linux. But "running" is not "infection."

*Infection* is whatever process brings the malware back for session after session. In Microsoft Windows systems, which are universally hard-drive based, malware adds or modifies something on the drive. A decade ago and more, malware would just drop some new files into the startup folder. Nowadays, malware may modify actual machine code in existing files, and then prevent normal file commands from seeing changes. In any case, something changes in start-up storage which somehow starts the malware.

The chances of running into malware in a normal browsing session, at least when actively avoiding danger, are small. The reason malware is an increasing problem is the *infection*, not the malware per se. If *infection* can be defeated, we can change malware from running during each full future session, to just the remaining session from the first encounter.

Puppy has an important and unique, yet unappreciated, facility. Merely by doing a DVD re-boot before online banking (or online investment, or online purchasing), any running malware can be ended. That is not the case for any hard-drive system.

And while many other "LiveDVD" systems exist, the ability to load the complete system into RAM, and thus remove the DVD and along with it even a slight DVD vulnerability, is rare.

But the really unique part is that DVD-load Puppy can do security updates to the existing programs without waiting perhaps months for somebody else. This is different from a hard-drive or USB update in that, if we do a reboot immediately before updating online and then a Save, we are quite unlikely to have malware running. We have no such assurance with a hard drive or USB flash system.

[tazoc]

What you see is what I see, so I was as confused as you. This is the log referenced by Pburn when it returns fail. I assume that Pburn functions by generating commands which are then executed, and when they fail, error messages are logged. Are you saying that when you try to erase a DVD-RW or DVD+RW on your system, failure does not happen?

Yes, although as Ted Dog noted earlier your drive needs to identified as /dev/sr0. This can be set up in Pburn -> File -> Preferences -> Burner device. Then click on your preferred burner and the corresponding device should appear in the entry box 'Burner device:'

Code: Select all

/dev/sr0

In my case I'm using the second burner, which on my system is /dev/sr1. I did a 'Fast blank' on a DVD+RW, though it still took a while:

Code: Select all

Pburn version 3.3.4

###################################################
   COMMAND:
###################################################

dvd+rw-format -force /dev/sr1

###################################################
   OUTPUT:
###################################################
* BD/DVD±RW/-RAM format utility by <appro@fy.chalmers.se>, version 7.1.
* 4.7GB DVD+RW media detected.
* formatting .0.0%|/-\|/-\|/-\|/-\|0.0%/-\|/-\|/-\0.2%0.1%0.2%0.2%|/-0.0%\|/ etc...

The blank was successful.

-TaZoC

[Q5sys]

It may or may not help to give some of my background, and there is a lot on my site:

To be honest, its not important to me but always nice to know where someone is coming from. For me the merit's of the argument alone should be sufficient to decide whether the person is worth listening to or not. As a person in the security field myself I'm always interested in the ideas and perceptions of others.

With respect to vulnerable store, the issue is less one of "removable" than it is "writable." Both hard drives and USB flash drives are instantaneously writable. Even in Puppy, these systems involve constant interaction with non-volatile store. In particular, it is common in these systems to access and rewrite disk "sectors," which are tiny fragments of files. These are easily read, modified for infection, and written, all in a fraction of a second. The infection process thus is just one more tiny flash of the activity LED among millions. The failure of indication is the failure of the last line of defense, because there are no tools which guarantee to find a hiding malware infection. Absent non-existent OS support, identifying all code which does bad things is theoretically impossible.

But you can have non writable USB media. I can think of two examples off the top of my head. 1st is using a SD card with a USB adapter. Load your system onto it, slide the lock down to read only, and make sure your hardware supports read only (since its dependant on the host receiver) and there you are. That's what I do on my ASUS netbook that I can boot off a SD card. The card is set to read only, so the system cant write to it.
2nd option is to get a USB with a physical read-only switch on it. I have a few of the Kanguru flashblu drives which have this. Its great, and it is hardware based so its totally OS independant. It's actually what I have my old LHP 4.43 install on.
Both of these can be set to read only, thus eliminating the possibility of the host OS writing to them. If the tinfoil brigade is still after you, you CAN remove the drive from the system once its up and running as long as you are running a frugal install and choose to load EVERYTHING into ram (including your safe file)

There is, and can be, no perfect security. All security comparisons are necessarily relative. The usual disk-install Puppy system has a continuous interaction with the hard drive (or USB flash), with continued drive activity flashes, just like Microsoft Windows, and is similarly vulnerable.

Agreed perfect security is not possible. But you can manage your risk. Which is exactly why I ONLY use frugal installs on removable media.

On the other hand, if Puppy would treat a USB flash drive similar to the way it treats a DVD, then we would have something! It would be a much faster load, and THEN WE WOULD REMOVE THE USB! I particularly would appreciate the DVD Save ability to keep multiple versions of files (in different directories), allowing one to go back to earlier article versions. That is what we could have, but it is not what we do have. We are necessarily forced to deal with what we have.

As I stated above actually you can remove the USB after you boot the system if you have a frugal install. You choose to load everything to ram and then once its loaded you remove the drive. I've done it many times. Sure you get nice pretty RED errors when it tries to save every 30 minutes, but the system still runs.

Is there any benefit you are gaining? Because it seems like you are dealing with a ton of headaches because of it.

First of all, I am unsure about this "ton of headaches" meme with respect to DVD-load operation. That certainly was true when I first started with Puppy, now several years ago, and it was very frustrating until I understood some of the problems and found solutions. Fortunately, all operations necessary to make DVD-load a practical mode are in fact available. These are not hard, or "headaches," just hidden. I use it all day, every day.

Well personally I'd call it a 'Cliche' rather than a 'meme' but thats neither here nor there isnt it. Actually the headache I was referring to is your problem getting the burning process to work properly. Using removable media like I explained above would negate all of these problems.

Puppy has an important and unique, yet unappreciated, facility. Merely by doing a DVD re-boot before online banking (or online investment, or online purchasing), any running malware can be ended. That is not the case for any hard-drive system.

And while many other "LiveDVD" systems exist, the ability to load the complete system into RAM, and thus remove the DVD and along with it even a slight DVD vulnerability, is rare.

But the really unique part is that DVD-load Puppy can do security updates to the existing programs without waiting perhaps months for somebody else. This is different from a hard-drive or USB update in that, if we do a reboot immediately before updating online and then a Save, we are quite unlikely to have malware running. We have no such assurance with a hard drive or USB flash system.

Puppy's ability to run in ram, as well as saving every bit of information into a single save file is why I came to puppy in the first place. For me it was because of the forensic benefit of it. I can use a live system that allows me to keep changes, yet if needed I can issue one command which will wipe all settings and everything in the safe file, and then nuke the system so it has to be rebooted.

Have you ever looked into Liberte linux or TAILS?
You may get some really neat ideas from those two distros.

[RandSec]

For me the merit's of the argument alone should be sufficient to decide whether the person is worth listening to or not.

I agree, and am willing to be judged at that level. There is, however, a deeper level: One may not even have to make the argument. The facts are what they are, and do not need my gloss on reality to rear their ugly heads. Anyone who addresses security in detail must encounter the same issues.

With respect to vulnerable store, the issue is less one of "removable" than it is "writable." Both hard drives and USB flash drives are instantaneously writable.

But you can have non writable USB media.

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.

I can think of two examples off the top of my head. 1st is using a SD card with a USB adapter. Load your system onto it, slide the lock down to read only, and make sure your hardware supports read only (since its dependant on the host receiver) and there you are. That's what I do on my ASUS netbook that I can boot off a SD card. The card is set to read only, so the system cant write to it.

While that may be true on your hardware, there is no such guarantee. The SD card write-enable "switch" is in fact just a plastic tab which is read by the reader. The effects of "write-enable" thus depend on the particular reader. Somewhere in discussions on the

http://krebsonsecurity.com/

site, one reader reported that while the OS appeared to respect the "write-enable" switch, *applications* were able to write the card anyway. Which of course means that malware could be expected to have similar or greater powers.

As bad as that is, it really is not the killer issue, which I expect to get to next.

2nd option is to get a USB with a physical read-only switch on it. I have a few of the Kanguru flashblu drives which have this. Its great, and it is hardware based so its totally OS independant. It's actually what I have my old LHP 4.43 install on.
Both of these can be set to read only, thus eliminating the possibility of the host OS writing to them. If the tinfoil brigade is still after you, you CAN remove the drive from the system once its up and running as long as you are running a frugal install and choose to load EVERYTHING into ram (including your safe file)

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.

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.

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.

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.

Agreed perfect security is not possible. But you can manage your risk. Which is exactly why I ONLY use frugal installs on removable media.

But that only works if you never flip the write-enable.

As I stated above actually you can remove the USB after you boot the system if you have a frugal install. You choose to load everything to ram and then once its loaded you remove the drive. I've done it many times. Sure you get nice pretty RED errors when it tries to save every 30 minutes, but the system still runs.

Just do not flip the write-enable.

Actually the headache I was referring to is your problem getting the burning process to work properly. Using removable media like I explained above would negate all of these problems.

The "burning process" works the way one should expect from the physical characteristics of a single helical track versus storage sectors. The "problem" is that our expectations are set by random-access drives which are inherently vulnerable to instantaneous and hidden malware changes. The problem I reported with erasing a DVD in Lighthouse64 does not exist in the 32-bit Puppies, where Pburn "just works." My contribution was to report a bug.

Puppy's ability to run in ram, as well as saving every bit of information into a single save file is why I came to puppy in the first place. For me it was because of the forensic benefit of it. I can use a live system that allows me to keep changes, yet if needed I can issue one command which will wipe all settings and everything in the safe file, and then nuke the system so it has to be rebooted.

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.

I worked hard trying to make Puppy on flash acceptable. I installed it and had it running multiple times. I tried various form of write-enable, and investigated their issues. I understand very well that someone might prefer the speed and convenience of a flash. In the end, though, I had to give it up, because I prize security more.

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.

[gcmartin]

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 (although I am aware that just because it hasn't been reported does not mean that its presence doesn't exist.)

That being said. I will make a one-time weigh-in (and then weigh-out) on this virus subject in LH64.

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.

Here to help

[meeki]

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.

[RandSec]

Sorry, but I think you are way off base here.

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.

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.

[Q5sys]

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)

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.

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.

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.

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.

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.

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.

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.

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.

[tazoc]

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: Select all

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.

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: Select all

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.

Thank you,
TaZoC

[Q5sys]

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.