SELinux insanity

Mon Dec 14 14:48:54 PST 2020

I know not what this "Danish Science" is.

There's science, and then there's everything else which is abused to
support one's agenda.  If all you've got to support a fringe
conspiracy theory are scientific discoveries from hundreds of years
ago, then you're grasping, desperately at straws.

On Mon, Dec 14, 2020 at 2:46 PM Leon Goldstein <metapsych at earthlink.net> wrote:
>
> Right, Lonni; Danish science is bunk.  Tycho Brahe knew nothing about
> astronomy and Niels Bohr knew nothing about making an atomic bomb.
>
> On 12/14/20 5:43 PM, Lonni J Friedman wrote:
> > Just because you proclaim something as "science" does not make it so.
> > It never ceases to amaze me how many people are self declared public
> > health experts based on racism, unsubstantiated rumors and widely
> > debunked conspiracies.
> >
> > Its quite sad how COVID19 has exposed the worst impulses of so many.
> >
> > On Mon, Dec 14, 2020 at 2:20 PM Leon Goldstein via Linux-users
> > <linux-users at linux-sxs.org> wrote:
> >> I don't know if any of you guys run SuSE these days, but it too has its
> >> very annoying quirks.  I just run Mint Mate and am very satisfied with it.
> >>
> >> Re Wuhan virus aka Covid 19:  make sure you are getting the full daily
> >> recommended dose of vitamin D.  That is science.  Face masks, "social
> >> distancng," lock downs etc. are political science. The Danes already
> >> demonstrated that face masks are of very doubtful value.
> >>
> >> On 12/14/20 5:11 PM, Matthew Carpenter via Linux-users wrote:
> >>> Hey Lonnie, I hope you'll let this one pass, it's been a while since I've flung
> >>> a distro-war comment:  Perhaps you need to get off RH stuff ;)
> >>>
> >>> jk!  I know that to each their own.  I get enough flack from running Ubuntu.
> >>> RH is a solid choice as well.  Each distros come with their own pain points.
> >>>
> >>>
> >>>
> >>> Anyway, more seriously...
> >>>
> >>> 1) Why do you have *anything* writing random temp files to /etc?
> >>>
> >>> 2) You can enable permissions by command.  So if you *want* sed to have write
> >>> access to /etc, I guess...
> >>>
> >>> 3) I'm guessing you may want to rewrite whatever tool/script you're using to
> >>> use a real temporary file.
> >>>
> >>> 4) I might consider trying /etc/hosts.deny as a symlink to a different location
> >>> (eg. /var/tmp/shitcan/hosts.deny), where you can give complete access to sed
> >>> without any real concerns.
> >>>
> >>> SELinux and AppArmor do serve a good purpose.  They *do* stop a lot of
> >>> exploits... and when they don't, they've pushed the attacker to be creative
> >>> and do a lot more work writing their exploit.  Believe me.
> >>>
> >>> I hope you are well, Lonnie.  I miss "hanging out" with you and the rest of
> >>> the gang.  It seems we've all grown up, as has Linux.  Still great to know you
> >>> are still here.
> >>>
> >>> Matt
> >>>
> >>>
> >>> On Monday, December 14, 2020 3:58:29 PM EST Lonni J Friedman via Linux-users
> >>> wrote:
> >>>> The problem is that the file is a sed generated temp file when its
> >>>> editing (note the randomly generated /etc/sedIYn1RO in the error msg),
> >>>> so I have no way of knowing the file name in advance.
> >>>>
> >>>> Thanks for the tip regarding audit2allow.  Unfortunately, its
> >>>> recommending making all of /etc/ writable with:
> >>>>
> >>>> allow fail2ban_t etc_t:dir write;
> >>>>
> >>>> I guess that's better than disabling SELinux altogether, but still kinda
> >>>> crappy.
> >>>> On Mon, Dec 14, 2020 at 12:54 PM James McDonald <james at toggen.com.au> wrote:
> >>>>> I'm reticent to make dumb suggestions as I know you are way more
> >>>>> experienced with this stuff then me but....
> >>>>>
> >>>>> Sounds like you need to change the policy or context of the file you are
> >>>>> doing the in place edit to to allow fail2ban to do it's thing.
> >>>>>
> >>>>> Have you tried audit2allow?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 15 Dec. 2020 7:16 am, Lonni J Friedman via Linux-users
> >>>>> <linux-users at linux-sxs.org> wrote:
> >>>>>
> >>>>> Hi folks,
> >>>>> Hope you're staying safe during these crazy times.  Happy holidays too
> >>>>> (if possible)!
> >>>>>
> >>>>> Remember SELinux?  That thing that Redhat forced upon the (linux)
> >>>>> world so many years ago?  It was supposed to make things more secure.
> >>>>> Its been a thing for such a long time, surely all the rough edges have
> >>>>> been smoothed out by now, right?
> >>>>>
> >>>>> Wrong.  I'm in the process of building out a new production
> >>>>> environment, and I keep tripping over random stuff that doesn't work
> >>>>> because SELinux isn't configured correctly out of the box.  I've
> >>>>> managed to tweak most of the issues, but there's one remaining bit of
> >>>>> SELinux pain that I'm struggling to fix.
> >>>>>
> >>>>> I've got fail2ban configured to manage /etc/hosts.deny for the bots
> >>>>> trying to brute force their way in via ssh.  I don't even permit
> >>>>> password auth, so this is really just to reduce the noise of auth
> >>>>> failures in my logs.  The problem is that SELinux is preventing
> >>>>> fail2ban from calling sed to manage /etc/hosts.deny.  Every time it
> >>>>> tries, it fails with this fun mess:
> >>>>>
> >>>>> 2020-12-13 03:20:32,938 fail2ban.utils          [2312]: ERROR
> >>>>> 7fe1d018cc00 -- exec: IP=$(echo "45.238.121.134" | sed
> >>>>> 's/[][\.]/\\\0/g') && sed -i "/^ALL: $IP$/d" /etc/hosts.deny
> >>>>> 2020-12-13 03:20:32,938 fail2ban.utils          [2312]: ERROR
> >>>>> 7fe1d018cc00 -- stderr: "sed: warning: failed to set default file
> >>>>> creation context to unconfined_u:object_r:net_conf_t:s0: Permission
> >>>>> deniedsed: couldn't open temporary file /etc/sedIYn1RO: Permission
> >>>>> denied"
> >>>>> 2020-12-13 03:20:32,938 fail2ban.utils          [2312]: ERROR
> >>>>> 7fe1d018cc00 -- returned 4
> >>>>> 2020-12-13 03:20:32,938 fail2ban.actions        [2312]: ERROR   Failed
> >>>>> to execute unban jail 'ssh-tcpwrapper' action 'hostsdeny' info
> >>>>> 'ActionInfo({'ip': '45.238.121.134', 'family': 'inet4', 'fid':
> >>>>> <function Actions.ActionInfo.<lambda> at 0x7fe1d06a2b80>,
> >>>>> 'raw-ticket': <function Actions.ActionInfo.<lambda> at
> >>>>> 0x7fe1d06a7280>})': Error unbanning 45.238.121.134
> >>>>>
> >>>>> sed system_u:system_r:fail2ban_t:s0 0 dir write
> >>>>> system_u:object_r:etc_t:s0 denied
> >>>>>
> >>>>> Other than making all of /etc writable, anyone have any suggestions
> >>>>> how to fix this so that fail2ban & sed can do what they need to do?
> >>>>>
> >>>>>
> >>>>> thanks!
> >>>>> _______________________________________________
> >>>>> Linux-users mailing list
> >>>>> Linux-users at linux-sxs.org
> >>>>> http://mailman.celestial.com/mailman/listinfo/linux-users
> >>>> _______________________________________________
> >>>> Linux-users mailing list
> >>>> Linux-users at linux-sxs.org
> >>>> http://mailman.celestial.com/mailman/listinfo/linux-users
> >>>
> >>>
> >>> _______________________________________________
> >>> Linux-users mailing list
> >>> Linux-users at linux-sxs.org
> >>> http://mailman.celestial.com/mailman/listinfo/linux-users
> >> --
> >> Leon A. Goldstein
> >>
> >> HP G7
> >> Linux Mint 18.3
> >>
> >> _______________________________________________
> >> Linux-users mailing list
> >> Linux-users at linux-sxs.org
> >> http://mailman.celestial.com/mailman/listinfo/linux-users
>
> --
> Leon A. Goldstein
>
> HP G7
> Linux Mint 18.3
>