Hi All;
I'm running Fedora 23 KDE Spin, After a recent firefox update (I'm now at Firefox 46.0.1) I've been getting these SELINUX alerts:
The source process: 57656220436F6E74656E74 Attempted this access: create On this rawip_socket:
The alert gives me 2 choices:
1) If I want to use the plugin package:
you must turn off SELinux controls on the Firefox plugins. # setsebool -P unconfined_mozilla_plugin_transition 0
2) If I believe that 57656220436F6E74656E74 should be allowed to create access on the Unknown rawip_socket by default:
You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
If I click on "Plugin Details" I get this:
SELinux is preventing 57656220436F6E74656E74 from create access on the rawip_socket Unknown.
Plugin: catchall you want to allow 57656220436F6E74656E74 to have create access on the Unknown rawip_socketIf you believe that 57656220436F6E74656E74 should be allowed create access on the Unknown rawip_socket by default. You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
Thoughts? Is this a bug? Should I run the setsebool command to allow access?
Thanks in advance
On 05/09/2016 12:19 PM, CS DBA wrote:
Hi All;
I'm running Fedora 23 KDE Spin, After a recent firefox update (I'm now at Firefox 46.0.1) I've been getting these SELINUX alerts:
The source process: 57656220436F6E74656E74 Attempted this access: create On this rawip_socket:
The alert gives me 2 choices:
- If I want to use the plugin package:
you must turn off SELinux controls on the Firefox plugins. # setsebool -P unconfined_mozilla_plugin_transition 0
- If I believe that 57656220436F6E74656E74 should be allowed to create
access on the Unknown rawip_socket by default:
You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
If I click on "Plugin Details" I get this:
SELinux is preventing 57656220436F6E74656E74 from create access on the rawip_socket Unknown.
Plugin: catchall you want to allow 57656220436F6E74656E74 to have create access on the Unknown rawip_socketIf you believe that 57656220436F6E74656E74 should be allowed create access on the Unknown rawip_socket by default. You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
Thoughts? Is this a bug? Should I run the setsebool command to allow access?
Smells fishy. I can't see an Internet website having any legitimate need to open a raw IP socket and I really don't see Firefox needing to do such a thing for normal operations. A web interface to an internal process, perhaps, but not a website.
BTW, the digits given, if used as a hex representation of a string, equate to "Web content". Hmmmmmmmmm......... I sure as heck wouldn't enable the boolean or add a policy. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - I haven't lost my mind. It's backed up on tape somewhere, but - - probably not recoverable. - ----------------------------------------------------------------------
On 05/09/2016 01:39 PM, Rick Stevens wrote:
On 05/09/2016 12:19 PM, CS DBA wrote:
Hi All;
I'm running Fedora 23 KDE Spin, After a recent firefox update (I'm now at Firefox 46.0.1) I've been getting these SELINUX alerts:
The source process: 57656220436F6E74656E74 Attempted this access: create On this rawip_socket:
The alert gives me 2 choices:
- If I want to use the plugin package:
you must turn off SELinux controls on the Firefox plugins. # setsebool -P unconfined_mozilla_plugin_transition 0
- If I believe that 57656220436F6E74656E74 should be allowed to create
access on the Unknown rawip_socket by default:
You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
If I click on "Plugin Details" I get this:
SELinux is preventing 57656220436F6E74656E74 from create access on the rawip_socket Unknown.
Plugin: catchall you want to allow 57656220436F6E74656E74 to have create access on the Unknown rawip_socketIf you believe that 57656220436F6E74656E74 should be allowed create access on the Unknown rawip_socket by default. You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
Thoughts? Is this a bug? Should I run the setsebool command to allow access?
Smells fishy. I can't see an Internet website having any legitimate need to open a raw IP socket and I really don't see Firefox needing to do such a thing for normal operations. A web interface to an internal process, perhaps, but not a website.
BTW, the digits given, if used as a hex representation of a string, equate to "Web content". Hmmmmmmmmm......... I sure as heck wouldn't enable the boolean or add a policy.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
-- I haven't lost my mind. It's backed up on tape somewhere, but -
probably not recoverable. -
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: http://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Should I be concerned that my laptop has been compromised? Time to install clamav? Or re-install fedora completely?
On 05/09/2016 12:19 PM, CS DBA wrote:
Thoughts? Is this a bug? Should I run the setsebool command to allow access?
https://bugzilla.redhat.com/show_bug.cgi?id=1230052
What plugins do you have installed? Flash?
On 05/09/2016 04:36 PM, Samuel Sieb wrote:
On 05/09/2016 12:19 PM, CS DBA wrote:
Thoughts? Is this a bug? Should I run the setsebool command to allow access?
https://bugzilla.redhat.com/show_bug.cgi?id=1230052
What plugins do you have installed? Flash?
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: http://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Yes, flash, no other plugins afaik
On 05/09/2016 03:30 PM, CS DBA wrote:
On 05/09/2016 01:39 PM, Rick Stevens wrote:
On 05/09/2016 12:19 PM, CS DBA wrote:
Hi All;
I'm running Fedora 23 KDE Spin, After a recent firefox update (I'm now at Firefox 46.0.1) I've been getting these SELINUX alerts:
The source process: 57656220436F6E74656E74 Attempted this access: create On this rawip_socket:
The alert gives me 2 choices:
- If I want to use the plugin package:
you must turn off SELinux controls on the Firefox plugins. # setsebool -P unconfined_mozilla_plugin_transition 0
- If I believe that 57656220436F6E74656E74 should be allowed to create
access on the Unknown rawip_socket by default:
You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
If I click on "Plugin Details" I get this:
SELinux is preventing 57656220436F6E74656E74 from create access on the rawip_socket Unknown.
Plugin: catchall you want to allow 57656220436F6E74656E74 to have create access on the Unknown rawip_socketIf you believe that 57656220436F6E74656E74 should be allowed create access on the Unknown rawip_socket by default. You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 57656220436F6E74656E74 --raw | audit2allow -M mypol # semodule -i mypol.pp
Thoughts? Is this a bug? Should I run the setsebool command to allow access?
Smells fishy. I can't see an Internet website having any legitimate need to open a raw IP socket and I really don't see Firefox needing to do such a thing for normal operations. A web interface to an internal process, perhaps, but not a website.
BTW, the digits given, if used as a hex representation of a string, equate to "Web content". Hmmmmmmmmm......... I sure as heck wouldn't enable the boolean or add a policy.
Should I be concerned that my laptop has been compromised? Time to install clamav? Or re-install fedora completely?
I wouldn't go so far as to reinstall. SELinux has blocked a request-- specifically from Firefox--to open a rawip socket and that's what it's supposed to do. Why Firefox tried to do that is a guess, but I think you visited a site with some evil Javascript stuff in it and it's the javascript that's trying to open the port. Since the Javascript would be running in the context of the browser, SELinux reported that Firefox was doing it. Note that antics such as this is another reason to not just blithely allow Javascript to run in your browser. I certainly don't.
So, to your question in more detail...
Are you compromised? Probably not. Emphasis on the "probably."
Is that website evil? If they're injecting Javascript to do things like this, yes and they should be beaten senseless and staked out over an anthill under a noon sun in the Sahara.
Should you ever just enable a boolean or set up a local policy? Not unless you research and understand WHY you'd do such a thing. They do have their uses at times.
Should you disable SELinux? Nope. Generally a bad idea.
Should you run a very restrictive firewall? Oh, yes, indeedy-do!
Should you run virus checkers such as clamav? Hell, yes!
Should you periodically scan your entire disk for viruses using whatever checker you have? Again, hell yes! (I run clamscan every night as a minimum).
Linux is a bit more impervious to the nefarious actions of the evil hackers out there than MacOS and a lot more so that Winblows, but it isn't perfect. If you're surfing the web, wear a full-body condom or two. And always remember the motto:
"Just because I'm paranoid doesn't mean they AREN'T out to get me!" ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "Microsoft is a cross between The Borg and the Ferengi. - - Unfortunately they use Borg to do their marketing and Ferengi to - - do their programming." -- Simon Slavin - ----------------------------------------------------------------------
On 05/09/2016 03:52 PM, Rick Stevens wrote:
On 05/09/2016 12:19 PM, CS DBA wrote:
- If I want to use the plugin package:
you must turn off SELinux controls on the Firefox plugins. # setsebool -P unconfined_mozilla_plugin_transition 0
I wouldn't go so far as to reinstall. SELinux has blocked a request-- specifically from Firefox--to open a rawip socket and that's what it's supposed to do. Why Firefox tried to do that is a guess, but I think you visited a site with some evil Javascript stuff in it and it's the javascript that's trying to open the port. Since the Javascript would be running in the context of the browser, SELinux reported that Firefox was doing it. Note that antics such as this is another reason to not just blithely allow Javascript to run in your browser. I certainly don't.
It's extremely unlikely to be javascript since javascript doesn't have that kind of access. Note what the message says. The boolean refers to "mozilla_plugin", so it's most likely flash.
Linux is a bit more impervious to the nefarious actions of the evil hackers out there than MacOS and a lot more so that Winblows, but it isn't perfect. If you're surfing the web, wear a full-body condom or two. And always remember the motto:
I have never used anti-virus software on a Linux computer. The only time I've seen malware on a Linux computer is when there has been a weak password on an account (generally root) and no rate-limiting on the ssh port.
On Mon, 2016-05-09 at 16:11 -0700, Samuel Sieb wrote:
Linux is a bit more impervious to the nefarious actions of the evil hackers out there than MacOS and a lot more so that Winblows, but
it
isn't perfect. If you're surfing the web, wear a full-body condom
or
two. And always remember the motto:
I have never used anti-virus software on a Linux computer. The only time I've seen malware on a Linux computer is when there has been a weak password on an account (generally root) and no rate-limiting on the ssh port.
+1
Not only have I never used AV software on a Linux computer (except in a mail server of course, where the users are running Windows), I have never even seen a Linux virus. I hear they exist, but those I've read about seem to have been developed as a proof of concept rather than a serious threat. Much more important is to keep tight control of logins from outside your network. Only allow SSH, don't allow it to the root account, only allow it using token (not password) access, and run fail2ban.
And keep SElinux enabled and enforcing.
poc
On 05/10/2016 01:03 AM, Patrick O'Callaghan wrote:
Much more important is to keep tight control of logins from outside your network. Only allow SSH, don't allow it to the root account, only allow it using token (not password) access, and run fail2ban.
Excellent advice. Linux never tells you if the username you're trying to log in with is right, just that the combination of username and password was wrong. The only username that a potential cracker knows exists is root, so if you allow remote log in as root, most of a cracker's job is already done. All they need to know is find the root password and your box is pw0ned. Once you've set ssh up not to allow remote root login, any cracker has to find the right combo of username and password before fail2ban and/or denyhost blocks them.
If you really want to be careful, don't put any regular users in the wheel group, including yourself, and don't set anybody up with sudo. It's your system, you installed it and you know the root password. Use su (or su - if you only need to run one command as root) because that way anybody who does get into your system via ssh doesn't get automatic admin access. And as far as taking my own advice, the only reason I have sudo installed is because some install/update scripts use it (I've no idea why, as they're already run as root.) and I've had updates barf if it's not there.
Allegedly, on or about 10 May 2016, Patrick O'Callaghan sent:
Much more important is to keep tight control of logins from outside your network. Only allow SSH, don't allow it to the root account, only allow it using token (not password) access, and run fail2ban.
If you run externally accessible mail services, then you should disallow plaintext authentication. That will stop mail clients from transmitting the user's password in the clear. Likewise if there are web server pages that require a login (ensure it's only allowed through an encrypted connection).
You should probably disallow it even for internal services, there could be something snooping on traffic elsewhere on your net. While some will say the war is already lost if they're doing that, I tend to feel that you're checkmating them if they can't get anything useful.
On Tue, May 10, 2016 at 01:30:48 -0700, Joe Zeff joe@zeff.us wrote:
Excellent advice. Linux never tells you if the username you're trying to log in with is right, just that the combination of username and password was wrong. The only username that a potential cracker knows exists is root, so if you allow remote log in as root, most of a cracker's job is already done. All they need to know is find the root
That is incorrect unless you are using very low entropy passwords. The difficulty of guessing a username should be much lower than that of guessing a password, so knowing a valid username should be almost no help to an attacker.
Also, because the kernel seems to have lots of local privilege elevation bugs, counting on being protected from total compromise if a normal user account is compromised is not a good idea.
On Wed, 2016-05-11 at 10:07 -0500, Bruno Wolff III wrote:
On Tue, May 10, 2016 at 01:30:48 -0700, Joe Zeff joe@zeff.us wrote:
Excellent advice. Linux never tells you if the username you're trying to log in with is right, just that the combination of username and password was wrong. The only username that a potential cracker knows exists is root, so if you allow remote log in as root, most of a cracker's job is already done. All they need to know is find the root
That is incorrect unless you are using very low entropy passwords. The difficulty of guessing a username should be much lower than that of guessing a password, so knowing a valid username should be almost no help to an attacker.
Also, because the kernel seems to have lots of local privilege elevation bugs, counting on being protected from total compromise if a normal user account is compromised is not a good idea.
Virtually every security measure is a partial solution. There are no magic bullets. However just because a given measure is weak on its own doesn't mean it isn't useful in combination with others. Using a non- root user for remote login means that the vast majority of drive-by attackers will give up and move on. A targeted attack is of course another matter.
poc
On 05/11/2016 08:51 AM, Patrick O'Callaghan wrote:
Virtually every security measure is a partial solution. There are no magic bullets. However just because a given measure is weak on its own doesn't mean it isn't useful in combination with others. Using a non- root user for remote login means that the vast majority of drive-by attackers will give up and move on. A targeted attack is of course another matter.
Exactly. And, of course, security is a matter of layers. Not allowing remote logins as root is one layer, using fail2ban and/or denyhosts is another. Searching for One Perfect Answer to the problem of crackers and script kiddies trying to get into our systems is a fool's errand, and rejecting anything less is a good way to get pw0ned. Remember, perfection is the enemy of "good enough for today."
-
Bruno Wolff III -
CS DBA -
Joe Zeff -
Patrick O'Callaghan -
Rick Stevens -
Samuel Sieb -
Tim