I am not taking issue with what you or anyone is sharing. I respect what all share.

And, I can see some of what you share. But, in truth, you, I and the rest of us should be trying to better understand and address "operational procedures" rather that "presence" for exploitation. In other words, presence does NOT spell exploitation. That is what members are getting from how you are presenting things. Exploitation does not occur as one can dirive from the methods you are sharing. Those conditions for exploitation must be met exactly in order for an exploitation to even begin much less operation for benefit or malice.

And, we also, should address it on the Security thread because what you are sharing is not specific to LH64, but more generally to all PUPs that have JRE offering or presence. I think you see the benefit.

But, I wont pursue JRE from a security flaw position as an exploit is not imminent based upon what I have read. And, as you share, there are steps being taken to keep JRE current as well as safe. This also is being done with so many products in today's arena. And should an potential for exploit be discovered does not make a product totally useless or mean that anyone is being currently exploited. As any security officer understands this. At least I am aware of this.

Please, lets try to understand that. While not ignoring potential harm from anything we use, we can and should pursue benefit in system and subsystem understanding and usage. And, in regards to the deliverable from LH64, we continue to get and use a very reasonably safe environment.

Here to help_________________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

I am not taking issue with what you or anyone is sharing. I respect what all share.

And, I can see some of what you share. But, in truth, you, I and the rest of us should be trying to better understand and address "operational procedures" rather that "presence" for exploitation. In other words, presence does NOT spell exploitation. That is what members are getting from how you are presenting things. Exploitation does not occur as one can dirive from the methods you are sharing. Those conditions for exploitation must be met exactly in order for an exploitation to even begin much less operation for benefit or malice.

And, we also, should address it on the Security thread because what you are sharing is not specific to LH64, but more generally to all PUPs that have JRE offering or presence. I think you see the benefit.

But, I wont pursue JRE from a security flaw position as an exploit is not imminent based upon what I have read. And, as you share, there are steps being taken to keep JRE current as well as safe. This also is being done with so many products in today's arena. And should an potential for exploit be discovered does not make a product totally useless or mean that anyone is being currently exploited. As any security officer understands this. At least I am aware of this.

Please, lets try to understand that. While not ignoring potential harm from anything we use, we can and should pursue benefit in system and subsystem understanding and usage. And, in regards to the deliverable from LH64, we continue to get and use a very reasonably safe environment.

Here to help

According to a study by Symantic, the typical zero-day attack lasts 312 days with some lasting as long as two and a half years.
http://users.ece.cmu.edu/~tdumitra/public_documents/bilge12_zero_day.pdf
This means that exploits have are actively used LONG before they are discovered by researchers. Researchers dont usually discover a flaw first. it's usually research done to try to uncover unknown behavior on systems thats discovered. Through this researchers become aware of the exploit and work to patch it. Most of the time, its an exploit being used that helps bring it to attention, however according to Symantic its not a quick discovery. So we arent magically at risk when a vulnerability becomes known, we've been at risk; we are now aware that we are.
Yes the Java community does well once a vulnerablity comes to light, but the fact that so many vulnerabilities have been found over time; shows that its a very buggy platform. And with exploits existing and being utilitzed long before the community becomes aware of it shows the level of risk the java software has associated with it. Thats the inherient problem in software development when you assume a reactionary philosophy. The developers are always far behind the curve, which sadly puts users even further back. Who suffers the most? The users of course.

The fact is the risk exists all the time,its impossible to eliminate all risk. What we must do is learn how to best manage risk. For each person the balance between risk and usability is different. But going back to your original claim with regards to Java, "There is no when we need it, we need it."; that's your personal choice on that balance. You cannot presume that everyone shares your opinion, just as I cant that they agree with mine. However presenting both sides of the debate allows others to choose where their choice lies.

If you want to discuss Java more, please make a java thread somewhere and we can continue.

Lets recap several things though from the last few posts of ours?
1) You stated that an attack on MS or Apple doesnt mean it'll work on linux. -- I showed that false with a simple compromise of a linux system running the same version of java we had available to us.
2) you made the claim that lhp was safe from any attack, and that java,flash couldnt compromised LHP. "Not in the past, not now!" -- Unless you are all knowning, and know every LHPs users experience and system, how can you possibly make this claim with any credibility? Furthermore showing the same version of Java being exploited on a *nix system shows how simple it is to accomplish. Any script kiddie can go download Metasploit and the exploit script and go.
3) you claim: "Those conditions for exploitation must be met exactly in order for an exploitation to even begin much less operation for benefit or malice." -- Automated attacks can scan networks for systems that can be exploited. After systems are discovered, its trivial to turn the preliminary result of a vulnerable system into a useful attack. What could be done once its found? Well, what can be done with a remote shell on a system? Answer: pretty much anything. That's the main benefit from running broswers as spot. Broswerspace now adays is a seperate ecosystem from the OS. Exploits can be created for broswers with no care for the underlying system. Once a remote shell is gained, the game is over.
Lastly, "That is what members are getting from how you are presenting things."
--How exactly are you aware of what members are thinking when they read my comments?

I'm basing my comments on facts that can be verified by anyone. You're comments seem to be based on your personal opinion on things that no human could possibly know (what other people are thinking, and absolute knowledge of whats happened in the past)._________________Last edited by Q5sys on Wed 31 Oct 2012, 10:38; edited 2 times in total

As a simple test in Precise 5.4 I have just moved my portable Linux QtWeb browser folder (which holds all QtWeb files and data) inside spot and it works, but I just downloaded a pet and it still went to /root/downloads/ which I had previously specified.

I then moved my spot folder to another location and all seems well, but my question is have I confined any exploits (other than a possible unclean download) to my spot folder?

@meeki - many thanks for your LH64 Dropbox pet, and those details for moving the folder off-save. Works a treat - hope to get around to testing your other offerings soon, ESPECIALLY subsonic, but I'm not joining all the dots lately...

As to my previous posting regarding mix/matching WM features (e.g., XFCE-4 Panel automatically starting up on Openbox bootup), I found what I was needing was to create an .sh script in the /root/Startup folder. At least - that is I think the solution to the problem I was having earlier,
Cheers_________________Toowoomba Linux Community
http://groups.google.com/group/toowoombalinux

Thanks for the alert notice, meeki...
Actually it was acting a little strange when I set it up in a native LH64 [edit] environment, but I thought it was the local thunderstorm playing havoc with my wifi... and then my mouse completed its slow death - strange selection behaviour that had me worried...
I'll use it judiciously in future - I note it seems to have removed itself from auto startup anyway (?)

Hi meeki - the dead mouse wasn't your fault - it was on the way out on its own but some (otherwise) unexplained behaviour in allowed and unallowed click selections across all apps tested, had me tricked for quite a while... No loss - the last of my wired MS mice

I must have been nearly the first one to download your dropbox pet - kept it for a rainy day. Didn't see or remember that you'd posted a retraction (that's my style). I do recall some unusual behaviour in LH64 after I loaded the pet for the first time yesterday, and perhaps I might have had to reboot shortly after I first tried to test it (it was late) - but it settled down completely and is doing as advertised on the tin. I've uploaded nearly 500mb of audio and visual material for vet students learning immunology, and colleagues have been able to access the files as per normal. It's still going on the last file as I write - uploading at about 10-28kb/sec, but I imagine that's more to do with my rural Aussie wifi than with any problem with your pet.
Now all I have to do is work out how to make the collection truly public without email invites, like I've seen for some personal Puppy repositories...
I'm using Tazoc's penultimate java sfs, in this setup.
Had a quick look at your subsonic pet too today - haven't organised media folders or a server client system yet, but it looks really cool. Thanks heaps again for taking up that challenge,
Cheers!_________________Toowoomba Linux Community
http://groups.google.com/group/toowoombalinux

As a simple test in Precise 5.4 I have just moved my portable Linux QtWeb browser folder (which holds all QtWeb files and data) inside spot and it works, but I just downloaded a pet and it still went to /root/downloads/ which I had previously specified.

I then moved my spot folder to another location and all seems well, but my question is have I confined any exploits (other than a possible unclean download) to my spot folder?

My regards

It doesnt so much matter where your files are as much as what user level the program is running at. If you are running your broswer as root, then any action carried out by that broswer (both good and bad) will be done with root access. So it doesnt matter if the files themselves are in a folder labeled spot. Root can go anywhere and do anything.
Also when a file is written with root, unless its specifically told NOT to have root permissions it will retain its root privilidge. Thus in the case of malware or some other nastyprogram; it'll be able to do whatever it wants later.

The reason most people suggest running a browser as spot, is that if you do get hit with something nasty, the limit of what that nasty thing can do is lowered severely. Yes if an attacker was able to obtain a remote spot level shell they could through certain privilege escalation attacks make it a root shell, but that involves another exploit be available. If might be, and it might not. Without knowing the specifics of a system its impossible for anyone to say what may or may not happen on any random system out there in the world.

However returning to the point, If you run any browser within LHP as spot, its actions 95% of the time are going to be limited to spot folders and spot privileges. This above anything else will protect you. That other 5% isnt worth getting into right now because its a rabbithole of possibilities you can fall into. Honestly the only 'real' immediate benefit to running a broswer as root for most users is the ability to save files anywhere. You can however make a downloads folder wherever you want on your system and allow spot access to it.

If you have further questions outside of LHP and how it works, send me a PM to discuss OR... start a thread somewhere and shoot me the link and I'll reply there. No reason to clutter up Taz's thread. _________________

lm_sensors-3.1.2-x86_64-1 is included in LH64 5.15 (see link in to new thread in first post.) Then in 5.15, temps, if supported by your hardware can be set up in GKrellM SysMonitor, right-click top of it -> Configuration -> Builtins -> Sensors.

Quote:

I also want to view djvu files in lhpup. is it possible to use a djvu pet of 32bit puppy in lhpup?!

No, please do not use a 32-bit Pet in LH64. Have you tried Evince, I think it can. Click on Update icon on the desktop -> Office -> select Evince -> OK. If not, install djvulibre-3.5.22-amd64 in PPM.

Quote:

do we have any repository for lhpup where from we can look for other pets/sfs?!

Lighthouse Update is the best way, to see the descriptions and insure you get Pets designed for the version you are running. Then try PPM if what you want is not there. Then make a request on the new thread.

Wrong thread for latest LH64 info_________________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 DogPileLast edited by gcmartin on Mon 05 Nov 2012, 20:29; edited 2 times in total

Wrong thread for latest LH64 info_________________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

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum