Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Ubuntu, does not 'Security Check' Snap packages.


  • Please log in to reply
43 replies to this topic

#31 rufwoof

rufwoof

  • Members
  • 104 posts
  • OFFLINE
  •  
  • Local time:05:23 AM

Posted 18 May 2018 - 12:34 PM

In fairness, the Linux and BSD communities along with the likes of Google and VLC do go to considerable lengths to reduce security threats ... single trusted provider, file/folder permissions, not running certain programs such as vlc as root ...etc. but Puppy Linux not only throws all of that to the wind - but worse - intentionally changes things to open up those security holes. The concept of 'my puppy installation is safe as its read-only' or whatever are bygone days with the advent of IOT ... where a breach into the LAN for even milliseconds can lead to sub-kernel viruses being installed into firmware/hardware/other devices sharing the same LAN etc.

 

Puppy is riddled with security holes. Incredibly easy to breach even via the likes of adverts displayed within trusted web pages. Such is the disinterest even the Puppy forum couldn't care less about security and still runs standard HTTP rather than HTTPS.


Debian and OpenBSD multiboot's


BC AdBot (Login to Remove)

 


#32 Mike_Walsh

Mike_Walsh

    Bleepin' 'Puppy' nut..!!


  • Members
  • 1,266 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:King's Lynn, UK
  • Local time:05:23 AM

Posted 18 May 2018 - 03:09 PM

~ Deleted as inappropriate ~

 

Mike.


Edited by Mike_Walsh, 18 May 2018 - 03:35 PM.

Distros:- Multiple 'Puppies'..... and Anti-X 16.1

My Puppy BLOG ~~~  My Puppy PACKAGES

Compaq Presario SR1916UK; Athlon64 X2 3800+, 3 GB RAM, WD 500GB Caviar 'Blue', 32GB Kingspec PATA SSD, 3 TB Seagate 'Expansion' external HDD, ATI Radeon Xpress 200 graphics, Dell 15.1" pNp monitor (1024 x 768), TP-Link PCI-e USB 3.0 card, Logitech c920 HD Pro webcam, self-powered 7-port USB 2.0 hub

Dell Inspiron 1100; 2.6 GHz 400FSB P4, 1.5 GB RAM, 64GB KingSpec IDE SSD, Intel 'Extreme' graphics, 1 TB Seagate 'Expansion' external HDD, M$ HD-3000 'Lifecam'.

 

KXhaWqy.gifFQ8nrJ3.gif

 

 


#33 rp88

rp88

  • Members
  • 2,967 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Local time:04:23 AM

Posted 18 May 2018 - 05:55 PM

Shouldn't the linux architecture of permissions reduce the harm that any malware can do? Or have I misunderstood the idea that programs tend to run with what might be described as full administrator permissions on windows but very rarely are they run as root on linux?

This is very bad news, especially as on linux you don't exactly have any antivirus products to use and online scanners like virustotal would find clean any linux file you uploaded to them simply by the fact they are only checking for windows malware.

Edited by rp88, 18 May 2018 - 05:56 PM.

Back on this site, for a while anyway, been so busy the last year.

My systems:2 laptops, intel i3 processors, windows 8.1 installed on the hard-drive and linux mint 17.3 MATE installed to USB

#34 Gary R

Gary R

    MRU Admin


  • Malware Response Team
  • 777 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:05:23 AM

Posted 19 May 2018 - 12:19 AM

Programs run with the permissions they need to perform the function they were designed to perform. That is the same whether they run in Linux or in Windows.

 

In both systems permission must be given by the User for a program to have root/administrator access.

 

However, since the average User (of both systems) has no real idea whether a program actually needs such access or not, then when prompted, they will often just click through the prompts and allow them.  So as such, permissions are not a particularly effective form of protection.



#35 rufwoof

rufwoof

  • Members
  • 104 posts
  • OFFLINE
  •  
  • Local time:05:23 AM

Posted 19 May 2018 - 06:05 AM

Programs run with the permissions they need to perform the function they were designed to perform. That is the same whether they run in Linux or in Windows.

 

In both systems permission must be given by the User for a program to have root/administrator access.

 

However, since the average User (of both systems) has no real idea whether a program actually needs such access or not, then when prompted, they will often just click through the prompts and allow them.  So as such, permissions are not a particularly effective form of protection.

'nix's permissions are generally (at least in quality versions) set such that User cannot grant root level permissions - excepting if that security model is intentionally or otherwise compromised by root granting User to do so. Permissions can be a very effective form of internal protection - difficult/impossible for User to elevate their privileges. It's pretty much game over on the security side if such privilege elevation can be achieved.


Edited by rufwoof, 19 May 2018 - 08:41 AM.

Debian and OpenBSD multiboot's


#36 Mike_Walsh

Mike_Walsh

    Bleepin' 'Puppy' nut..!!


  • Members
  • 1,266 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:King's Lynn, UK
  • Local time:05:23 AM

Posted 19 May 2018 - 09:05 AM

...'nix's permissions are generally (at least in quality versions) set such that User cannot grant root level permissions...

 

 

....i.e., Debian or FreeBSD, n'est-ce pas?

 

Keep 'pushing it', Ruffers. About the only time you ever seem to show up on here is to 'knock' something I've posted.

 

Same old, same old gets boring.....fast.

 

 

Mike. :rolleyes:


Edited by Mike_Walsh, 19 May 2018 - 09:29 AM.

Distros:- Multiple 'Puppies'..... and Anti-X 16.1

My Puppy BLOG ~~~  My Puppy PACKAGES

Compaq Presario SR1916UK; Athlon64 X2 3800+, 3 GB RAM, WD 500GB Caviar 'Blue', 32GB Kingspec PATA SSD, 3 TB Seagate 'Expansion' external HDD, ATI Radeon Xpress 200 graphics, Dell 15.1" pNp monitor (1024 x 768), TP-Link PCI-e USB 3.0 card, Logitech c920 HD Pro webcam, self-powered 7-port USB 2.0 hub

Dell Inspiron 1100; 2.6 GHz 400FSB P4, 1.5 GB RAM, 64GB KingSpec IDE SSD, Intel 'Extreme' graphics, 1 TB Seagate 'Expansion' external HDD, M$ HD-3000 'Lifecam'.

 

KXhaWqy.gifFQ8nrJ3.gif

 

 


#37 Gary R

Gary R

    MRU Admin


  • Malware Response Team
  • 777 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:05:23 AM

Posted 19 May 2018 - 10:31 AM

 

Permissions can be a very effective form of internal protection - difficult/impossible for User to elevate their privileges. It's pretty much game over on the security side if such privilege elevation can be achieved.

 

If my time working on the help forums has taught me anything, it's that permissions are not a good form of defence against a determined attacker. Like it or not, there are a number of ways for an attacker to elevate the privileges they inherit when they initially breach your defences, and the bad guys generally know quite a few of them.

 

In Windows, it's supposedly impossible for a User to attain System level privileges (which are higher than Administrator level), and yet a number of Malwares seem to be able to run with System level access.

 

I'm not saying for a moment that it's easy to escalate permissions, but it's a long, long way from being impossible for a person with the necessary skills.



#38 rufwoof

rufwoof

  • Members
  • 104 posts
  • OFFLINE
  •  
  • Local time:05:23 AM

Posted 19 May 2018 - 12:59 PM

 

...'nix's permissions are generally (at least in quality versions) set such that User cannot grant root level permissions...

 

 

....i.e., Debian or FreeBSD, n'est-ce pas?

 

Keep 'pushing it', Ruffers. About the only time you ever seem to show up on here is to 'knock' something I've posted.

 

Same old, same old gets boring.....fast.

 

 

Mike. :rolleyes:

 

 

Highlighting that "the hoops through" you and other Puppiest have had to jump to circumvent reasonable security measures providers have implemented for good reason is a worthy warning to repeat as oft as necessary so others are made aware of the risks such actions induce.

 

Yes Debian and the BSD core levels respect security and audit accordingly. There are distinct benefits from having a single trusted provider of the system and audited programs via secure channels, patching and updating regularly as required, and designing/delivering layout and permissions in a protective manner ...etc. And yes I run/use both Debian and OpenBSD.

 

I would have thought you'd have some respect for how it is not a good idea to circumvent the likes of VLC and Chrome so that they can be run as root when they have been specifically designed to avoid being run as root for security reasons. Increasingly however its become evident that you and other Puppiest have no regard for such security matters.

 

Ubuntu made a mistake in combining official in house release of software alongside third party software and where security auditing of that third party software was clearly absent. Made worse by how close the two offerings are, indistinguishable for some less aware users.


Debian and OpenBSD multiboot's


#39 rufwoof

rufwoof

  • Members
  • 104 posts
  • OFFLINE
  •  
  • Local time:05:23 AM

Posted 19 May 2018 - 01:22 PM

If my time working on the help forums has taught me anything, it's that permissions are not a good form of defence against a determined attacker. Like it or not, there are a number of ways for an attacker to elevate the privileges they inherit when they initially breach your defences, and the bad guys generally know quite a few of them.

 

Totally agree, it is often extremely easy to elevate privileges. Respected providers will generally strive to provide a default case of very tight security, difficult to privilege elevate - and fixing cases where that was found to be possible. As changes/additions/deletions are made to that core base provided setup however often vulnerabilities are introduced and that more often are the means via which undesired access is achieved. There are no defences against a determined attacker, at least not excepting the exceptional cases - where the system would be unusable in the context of any meaningful general manner. Not that such vulnerability should have us throw caution to the wind and simply forget about security methods such as file/folder permissions. As interconnectivity increases so also do the risks from casualness.


Debian and OpenBSD multiboot's


#40 Mike_Walsh

Mike_Walsh

    Bleepin' 'Puppy' nut..!!


  • Members
  • 1,266 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:King's Lynn, UK
  • Local time:05:23 AM

Posted 19 May 2018 - 05:46 PM

I would have thought you'd have some respect for how it is not a good idea to circumvent the likes of VLC and Chrome so that they can be run as root when they have been specifically designed to avoid being run as root for security reasons. Increasingly however its become evident that you and other Puppiest have no regard for such security matters.

 

TBH, Ruffers, it shows you haven't been paying attention as of late. If you had, you would have seen that we've had no choice but to run Chrome et al as a 'normal' user (in this case, spot) for the last 4 or 5 releases. Google simply won't permit it any other way now.....not if you want to maintain sandboxing, and the other built-in security protocols.. And even I'm not daft enough to use the

--no-sandbox

.....'switch' in the wrapper script any longer. After all, it's slightly crazy not to take advantage of the multiple security protocols available to the browser.....especially when they're provided free of charge, along with the browser itself. The current Chromium-based offerings are very much a 'team effort', with contributions from several individuals over the last year or two.....to enable their use with Puppy, at the same time as running them in the secure manner in which they were intended to be run.

 

And then there's the business of the downloads. Peebee (who, as you know, packages Chromium for Puppy) and I have taken somewhat different routes over this. Peebee has packaged Chromium to download stuff as 'spot'.....but then immediately makes it available to the entire system by transferring it straightaway to the main Downloads folder with root:root permissions. I had a wee think about this, and came to the conclusion that the decision over whether to leave the download as is with normal 'user' (spot) permissions, or to transfer it to the main Downloads directory and give it root:root permissions should be left to the individual.

 

So; my current Chrome and Iron packages include a couple of small scripts that place a large green 'tick' in the notification area. If you want to transfer your downloaded item to the main Downloads directory (and make it available to the rest of the system), then you just click on the green checkmark.....and it moves it across and changes permissions for you.

 

To me, one of the great things about Linux in general (and Puppy in particular) is the matter of maximum choice in all things. It's not my place to hold the hand of other Puppians, to mollycoddle them, and to make their choices for them.....but as a responsible 'packager', to me those choices should be made available to the end user, along with clear definitions as to what is and isn't considered safe. The decision is then down to the individual; remember, one of Puppy's main 'selling-points' over the years has been that the user is in total control of their entire system.

 

-----------------------------------------------------------------------------------------

 

Aye, it's true that in the past we did indeed take advantage of the method Google had set in place for developers to run multiple versions while they were working on JavaScript, CSS templates, etc. It was the only reason even then that we were able to make the browser run as root. Since Chrome 61 or 62, Google put in place a different set of protocols, so that even developers would no longer have to take the 'risk' of running-as-root.

 

Puppy does move with the times, as you're aware yourself from your experiments with BK's new EasyOS, where everything runs in sandboxed containers. I think even you grudgingly admit that it's somewhat more secure like that.....and who knows, it may even turn out to be the direction Puppy itself follows in years to come.

 

T'internet landscape is vastly different from what it was nearly 15 years ago, when Puppy first appeared on the scene.....

 

 

Mike. :wink:


Edited by Mike_Walsh, 19 May 2018 - 07:02 PM.

Distros:- Multiple 'Puppies'..... and Anti-X 16.1

My Puppy BLOG ~~~  My Puppy PACKAGES

Compaq Presario SR1916UK; Athlon64 X2 3800+, 3 GB RAM, WD 500GB Caviar 'Blue', 32GB Kingspec PATA SSD, 3 TB Seagate 'Expansion' external HDD, ATI Radeon Xpress 200 graphics, Dell 15.1" pNp monitor (1024 x 768), TP-Link PCI-e USB 3.0 card, Logitech c920 HD Pro webcam, self-powered 7-port USB 2.0 hub

Dell Inspiron 1100; 2.6 GHz 400FSB P4, 1.5 GB RAM, 64GB KingSpec IDE SSD, Intel 'Extreme' graphics, 1 TB Seagate 'Expansion' external HDD, M$ HD-3000 'Lifecam'.

 

KXhaWqy.gifFQ8nrJ3.gif

 

 


#41 rufwoof

rufwoof

  • Members
  • 104 posts
  • OFFLINE
  •  
  • Local time:05:23 AM

Posted 19 May 2018 - 08:28 PM

as you're aware yourself from your experiments with BK's new EasyOS, where everything runs in sandboxed containers. I think even you grudgingly admit that it's somewhat more secure like that

 

IIRC I said it (Barry's EasyOS) was great Mike, not grudgingly so either and instead I strove to encourage further interest/avenues. Helped out as much as I could, but I have been barred from posting further security/other observations (when people start swearing at me directly both privately and in public I tend to react, so deservedly so) - so its well off my radar now (all my puppy references/bookmarks have been wiped clean from my systems). EasyOS is a step in the right direction, but still leaving a lot to be done. Such as better controls in respect to vendors who provide binary device drivers as binary objects (Blobs such as network or video drivers) that Linux loads into the kernel ... and which could do anything. Memory/kernel randomisation so things don't load/sit in memory in a consistent manner that is more easily hacked. Limiting individual programs to what they are expected to do/use and restrict access/execution of 'unusual' activities. Running X in a in a more secure manner. Better control/auditing of repositories ...etc. etc. Much of hacking nowadays is more about achieving even just brief access to individual systems along with privilege elevation in order to install into kernel or lower layers (firmware/hardware), hacking entire LAN's rather than individual systems.

 

Others do take security more seriously than Ubuntu. Second time that I am aware of that Ubuntu has enabled untrustworthy content to be sourced via their repos, and along with bricking some systems via a system 'upgrade' a while back ... IMO they do need to get their act together.


Edited by rufwoof, 19 May 2018 - 08:31 PM.

Debian and OpenBSD multiboot's


#42 Gary R

Gary R

    MRU Admin


  • Malware Response Team
  • 777 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:05:23 AM

Posted 20 May 2018 - 12:46 AM

 

Not that such vulnerability should have us throw caution to the wind and simply forget about security methods such as file/folder permissions. As interconnectivity increases so also do the risks from casualness.

 

I agree, permissions have an important function to play, such as in separating the data from different User accounts so that the currently logged on User can only see his/her own data, and are useful for segregating data for other purposes as well. They're just not as good a security method as some would have you believe.

 

However, to get back to the original point of this topic, I recently found this ... https://itsfoss.com/snapstore-cryptocurrency-saga/ ... which is quite an interesting read.


Edited by Gary R, 20 May 2018 - 04:43 AM.


#43 rufwoof

rufwoof

  • Members
  • 104 posts
  • OFFLINE
  •  
  • Local time:05:23 AM

Posted 20 May 2018 - 06:44 AM

I recently found this ... https://itsfoss.com/snapstore-cryptocurrency-saga/ ... which is quite an interesting read.

 

From that link

Canonical says “it’s impossible for a large scale repository to only accept software after every individual file has been reviewed in detail”. Therefore, they need to trust the source, not the content. After all, that is what the current Ubuntu repo system is based on.

 

IMO ... Ubuntu (correct behaviour) -> Skelm (untrustworthy)

 

A Debian Testing based derivative with security risks. Little wonder that periodically it can brick your system or simply contain viruses.

 

On the plus side - I guess we need a vast expanse of lab rats to help discover the risks that some would prefer to minimise/avoid themselves. The downside of having a more stable/secure choice is that of "lagging the curve". Personally I'm quite content to lag, most of my kit is old hand-me-downs anyway and the software does what I need it to do (bells and whistles added on top are nice, but not necessities).


Debian and OpenBSD multiboot's


#44 Gary R

Gary R

    MRU Admin


  • Malware Response Team
  • 777 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:05:23 AM

Posted 20 May 2018 - 07:51 AM

Yes, never been an "early adopter" myself either.

 

Security wise, I've always believed it's preferable to adopt a "wait and watch" strategy, since anything that's buggy or suspect will usually reveal itself in a relatively short time.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users