Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 19 Jun 2018, 02:14
All times are UTC - 4
 Forum index » Off-Topic Area » Security
Is Full Install Secure?
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 3 [38 Posts]   Goto page: Previous 1, 2, 3
Author Message
perdido


Joined: 09 Dec 2013
Posts: 799
Location: ¿Altair IV , Just north of Eeyore Junction.?

PostPosted: Sat 26 May 2018, 06:19    Post subject:  

bigpup wrote:
If you have one of those talking head devices in your home. (Amazon Echo, Alexa, etc....)
There is no security!!!!

Story is all over the news.
Quote:
Amazon Echo Recorded And Sent Couple's Conversation — All Without Their Knowledge


Oh, but I have nothing to hide so I am ok with that <g>
The convenience factor outweighs anything else <g>
Just a minute while I wait for my windows pc to boot so I can verify your link using bling search <g>
Then I will talk to my toaster and make a cup of auto coffee using my new tv <g>
Later I will use my self driving car <g> while talking on my google android <g> while I order from my amazon account <g>, that is so convenient that they make deliveries into my home while I'm away <g>

And a full install is not secure??? LOL, You have a better chance of catching a virus from cat farts than anything done in a full install.



.

_________________
Giving with an expectation for return brings misery.
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1529
Location: The other Mr. 305

PostPosted: Sat 26 May 2018, 11:42    Post subject:  

In my opinion, the only real threat to a full install is that you can screw up programs that are currently working by trying to update or by adding other program packages that may conflict.

That, my friend, can completely ruin your full install and make you wish you didn't do it. Of course, as long as you backup your important files, you can always do a reinstall.

The other threat is web-browsing and I would worry about internet banking with an older browser OR maybe even with a newer one. But that's not a Puppy issue, that's a worldwide issue.

I've been using TrueCrypt for years along with Ccrypt and have never seen a malware issue, though I'm not surprised they exist.

Oh, and I personally never use any of those software applications that supposedly save all of your logins and passwords. Write 'em down and keep them in a drawer; don't be foolish and ask for trouble....
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2365

PostPosted: Tue 05 Jun 2018, 19:45    Post subject:  

greengeek wrote:
There are other methods to improve security too - mostly focusing on ensuring that system files are readonly and contained within "sfs" files - not contained as read/write files as is done in a full install or a frugal+save.

Never tried it, and can't at present as running OBSD which for security reasons doesn't support layering (SFS's), but wondering how layering caters for dealing with a file that is ro at the bottom layer, but where a higher layer has a alternative version. When layered does the bottom layer 'shine through' (as it should) or does a higher layer version get 'revealed' instead? (Can't imagine that it would as that would be a serious flaw). If a sfs is loaded into memory, then even a ro sfs could still conceptually be operationally tampered with i.e. by changing the referenced ram content - perhaps even more so if being loaded consistently in the same manner (OBSD specifically randomises things in memory after each new boot).

Agree with others. If breaking out of user to root was easy, then server providers would be chasing their tails. A browser running as user has just as much prospect of elevating privileges. The better "prospect" (for dark side hackers) is to find flaws in the kernel processing of privilege based tasks, or flaws in programs that run under a privileged PID.

For me, completely reinstalling from fresh is a 5 minute task. I have OBSD fully installed and its ramdisk is just 9KB, pulls the rest down via http/ftp and is around 8 mostly ENTER's to then be ready to boot to desktop. Tar backup's/restores are relatively quick also. Much of the longer backup/restores is data. OBSD comes pre-set to be secure and unlike Linux - being just a kernel, includes both kernel and userspace which collectively are under regular security audit review. Kernel, bins, libs .... and even X (their own more secure version). The bummer is that it does run slower, especially disk synchronous/secure transfer. You can easily turn that off (async) which does help with speed, but sacrifices security and stability. I liken it to flying. Do I want to board a flight that will get me somewhere in 3 hours, but where the boarding process is clearly insecure and the pilots pre-flight checks consist of just kicking the tyres ... or board a flight where it takes 4 hours, but security and pre-flight checks are much more rigorous. In practice once flying, the speed differences are much less apparent especially when most of activity is being cached in ram.

The other factor is provider. Windows boxes tend to have software installed from here-there-everywhere. Linux have top of tree providers such as Debian who do a reasonable job of checking consistency and security across programs - but where holes are all too apparent (1700 vulnerabilities across all of the kernel + programs on my Jessie based system that I had installed a few months ago). Let alone others such as Ubuntu who take Debian's stuff and "improve" things (add in security flaws - more lines of code = more potential risks introduced). And I was running Debian Main repos only, dread to think what the count might have been by the time other repos were added in on top of that.

Whew! Enough! I'm off to boot my easy-pyro MMC to investigate sfs layering further.
Back to top
View user's profile Send private message 
nosystemdthanks

Joined: 03 May 2018
Posts: 168

PostPosted: Wed 06 Jun 2018, 03:28    Post subject:  

i wouldnt expect permissions from existing files to shine through sfs layers. i mean lets figure a few permutations of that:

1.ro bottom file / rw top file

since only root can mount sfs (whether puppy everything-is-root or other distro) you would expect that the permissions for the top layer would be the ones that count


2.ro bottom file / NO top file

if this is what you meant then of course you would expect perms to shine through, since there is nothing on top to contradict (using sfs shouldnt make every already-existing file rw)


3. rw bottom file / ro top file

you would probably want ro to be ro here-- not for rw to shine through.


whether editing the file in the sfs affects the file underneath or not (i would expect it to affect the file in the sfs, and leave the "bottom file" untouched) im trying to figure out why you would EVER want the perms of the mounted (top) sfs to be ignored or to count "second." but apologies if i misunderstood.

_________________
philosophy is important to software design; coding is useful for demonstrating design concepts
Back to top
View user's profile Send private message Visit poster's website 
rufwoof

Joined: 24 Feb 2014
Posts: 2365

PostPosted: Wed 06 Jun 2018, 05:22    Post subject:  

Quote:
1.ro bottom file / rw top file

since only root can mount sfs (whether puppy everything-is-root or other distro) you would expect that the permissions for the top layer would be the ones that count

... that is the particular case I have in mind. ro main sfs at the bottom, rw layer on top of that, that records any changes. B bottom ro layer, C changes rw layer, T top layer that 'shows' (formed by C overlaid on top of B).

Such a structure employs .wh files to indicate deleted files. The changes (C) layer is also rw by anyone, so for instance a user "deleting" /home/user/.profile file stored in the B ro bottom sfs layer would be recorded as something like a /home/user/.wh..profile file created in the C layer, so that /home/user/.profile file isn't 'shown' in the Top (T) layer. My thoughts are that as the changes (C) layer is rw, then even though I haven't a particular exploit/method/example in mind, it just feels like it could contain potential security risks.

I suspects its as good as conventional (non layered) file/folder permission security, some such as OpenBSD however do frown upon such methods, so I suspect there are additional security risks involved - perhaps such as the layering structure recorded in memory potentially being editable in a undesired manner if stored in a non W^X region (which I believe would be the 'natural' case under Linux anyway in not implementing W^X). If OBSD with their W^X and kernel/memory randomisation are reluctant to employ squashfs overlays, its somewhat uncomfortable using such in even less security conscious alternatives such as Linux!

My guess is that full install would be more secure than frugal T = B + C type layering (main sfs + save/changes).
Back to top
View user's profile Send private message 
greengeek


Joined: 20 Jul 2010
Posts: 5045
Location: Republic of Novo Zelande

PostPosted: Wed 06 Jun 2018, 05:32    Post subject:  

rufwoof wrote:
... but wondering how layering caters for dealing with a file that is ro at the bottom layer, but where a higher layer has a alternative version. When layered does the bottom layer 'shine through' (as it should) or does a higher layer version get 'revealed' instead?
Very good question. I would imagine that the highest layer always takes precedence - even if it changes a ro file to an rw file.

However - the result should surely only be revealed during a live session - in a properly configured system that "override" should not be allowed to contaminate the next boot by being incorporated into the saved data. (unless of course the user specifically requests it by virtue of updating a savefile or save folder).

Contamination of a session is possible using the method you describe - but how can this be avoided? Avoidance of "in session" contamination is the goal of every browser update (or ssl update, or wget update etc etc etc) but in the end there will never be totally secure system i suspect.

As far as I can tell, full installs never allow any mechanism to exist that locks out "in session" contamination - such contamination always become permanent and reflected in every subsequent boot.
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2365

PostPosted: Wed 06 Jun 2018, 12:17    Post subject:  

greengeek wrote:
Contamination of a session is possible using the method you describe - but how can this be avoided? Avoidance of "in session" contamination is the goal of every browser update (or ssl update, or wget update etc etc etc) but in the end there will never be totally secure system i suspect.

As far as I can tell, full installs never allow any mechanism to exist that locks out "in session" contamination - such contamination always become permanent and reflected in every subsequent boot.

Doesn't something like Suricata do that, unusual behaviour/action type detection? Simpler Intrusion Detection System (IDS) such as mtree are already a integral part of OpenBSD - that in effect just run a checksum against each file and compare to a known clean checksum value. More usually set to monitor /bin, /sbin and /usr - and where /bin and /sbin validation flashes by very quickly, but /usr takes much longer ..... Just run mtree interactively on my obsd system for instance that has kdenlive, libreoffice ...etc i.e. a lot of libs and and time ids (my setup) 4m14.43s real 1m48.82s user 0m31.55s system

Attached is a snippet from Mastering FreeBSD and OpenBSD Security By Yanek Korff, Paco Hope, Bruce Potter
s.jpg
 Description   
 Filesize   69.36 KB
 Viewed   109 Time(s)

s.jpg

Back to top
View user's profile Send private message 
cousinFrancis

Joined: 06 Jun 2018
Posts: 10

PostPosted: Wed 06 Jun 2018, 15:23    Post subject:  

perdido wrote:
bigpup wrote:
If you have one of those talking head devices in your home. (Amazon Echo, Alexa, etc....)
There is no security!!!!

Story is all over the news.
Quote:
Amazon Echo Recorded And Sent Couple's Conversation — All Without Their Knowledge

Oh, but I have nothing to hide so I am ok with that <g>
The convenience factor outweighs anything else <g>
Just a minute while I wait for my windows pc to boot so I can verify your link using bling search <g>
Then I will talk to my toaster and make a cup of auto coffee using my new tv <g>
Later I will use my self driving car <g> while talking on my google android <g> while I order from my amazon account <g>, that is so convenient that they make deliveries into my home while I'm away <g>

And a full install is not secure??? LOL, You have a better chance of catching a virus from cat farts than anything done in a full install.

Laughing
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 3 [38 Posts]   Goto page: Previous 1, 2, 3
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Security
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1070s ][ Queries: 15 (0.0198s) ][ GZIP on ]