Re: [CentOS] It's been six days since CVD-2021-33909 was patched in RHEL, what's the holdup for Stream 8?

[Carl George]

kernel-4.18.0-326.el8 is being pushed to the mirrors now.

On Wed, Jul 28, 2021 at 2:42 PM Brian Stinson  wrote:
>
> Carl summarized really well how code moves through RHEL and CentOS
> Stream, and we’re working on making sure we publish a build that has
> made it through the usual set of RHEL tests. -326 is a possible
> candidate here.
> Think about CentOS Stream as the development location for the next-minor
> release of RHEL.  I’d like to highlight some of the general points
> related to this discussion:
> - There are certain classes of CVE that we handle differently from
> normal development work:
> https://centos.org/distro-faq/#q4-how-will-cves-be-handled-in-centos-stream
> 
> - Since these fixes need to go into RHEL first, getting them into the
> development location (CentOS Stream) represents a separate set of work.
> - Our intent is to get CVE fixes like this into Stream as soon as
> they’re available within the guidelines referenced in the FAQ
> In the past updates have gone out quickly, we haven’t artificially held
> up pushes and we will not do so going forward. We don’t, though, make
> any forecasts or guarantees about turnaround time, this is to make sure
> we deliver those fixes correctly.
> I hope that as we continue rolling out new workflows in CentOS Stream 9,
> we will be able to provide more direct feedback on patch status at a
> source code level. Just as a reminder you can view and participate in
> development happening on Gitlab:
> https://gitlab.com/redhat/centos-stream/
> 
> --Brian
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Carl George

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] hosts.deny, fail2ban etc.

[Kenneth Porter]

On 7/28/2021 1:57 PM, Scott Techlist wrote:

Is that an improvement?  I'm still running Centos7 so I'm not familiar with it.


https://ungleich.ch/en-us/cms/blog/2018/08/18/iptables-vs-nftables/


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] hosts.deny, fail2ban etc.

[Scott Techlist]

>> For what it’s worth, if you use the fail2ban-firewalld package, it uses 
>> ipset rather than iptables, which is more efficient.
>
>That’s in CentOS 7 though. 

>CentOS 8 firewalld uses nft instead of the older netfilter (iptables/ipset) 
>code.

Is that an improvement?  I'm still running Centos7 so I'm not familiar with it.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] It's been six days since CVD-2021-33909 was patched in RHEL, what's the holdup for Stream 8?

[Brian Stinson]

Carl summarized really well how code moves through RHEL and CentOS
Stream, and we’re working on making sure we publish a build that has
made it through the usual set of RHEL tests. -326 is a possible
candidate here.
Think about CentOS Stream as the development location for the next-minor
release of RHEL.  I’d like to highlight some of the general points
related to this discussion:
- There are certain classes of CVE that we handle differently from
normal development work:
https://centos.org/distro-faq/#q4-how-will-cves-be-handled-in-centos-stream

- Since these fixes need to go into RHEL first, getting them into the
development location (CentOS Stream) represents a separate set of work. 
- Our intent is to get CVE fixes like this into Stream as soon as
they’re available within the guidelines referenced in the FAQ
In the past updates have gone out quickly, we haven’t artificially held
up pushes and we will not do so going forward. We don’t, though, make
any forecasts or guarantees about turnaround time, this is to make sure
we deliver those fixes correctly. 
I hope that as we continue rolling out new workflows in CentOS Stream 9,
we will be able to provide more direct feedback on patch status at a
source code level. Just as a reminder you can view and participate in
development happening on Gitlab:
https://gitlab.com/redhat/centos-stream/

--Brian

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] It's been six days since CVD-2021-33909 was patched in RHEL, what's the holdup for Stream 8?

[Steven Rosenberg via CentOS]

Thank you for the update and your candor on this.

Jul 28, 2021, 9:44 AM by c...@redhat.com:

> It's being worked on.  RHEL maintainers can fix things independently
> in different minor version branches.  The fix was applied to the
> internal 8.4 branch while it was under embargo.  It has since been
> released in RHEL 8.4, which allowed it to be rebuilt in CentOS Linux
> 8.  CentOS Stream 8 is currently tracking the internal 8.5 branch,
> which just had the fix merged yesterday, along with many other
> changes, as kernel-4.18.0-326.el8.  That build is going through QA
> now.  Once completed, it will be exported to git.centos.org and
> rebuilt in CentOS Stream 8.  This is the "inside out" process we've
> referred to, and we know it's not ideal.  CentOS Stream 9 improves on
> this significantly with RHEL maintainers doing their builds directly
> in the CentOS project, in the public.
>
> I'll also note this isn't something new.  We've been clear that RHEL
> gets some security fixes first.  Typically it's only 1-2 days after
> RHEL 8 that we'll have the corresponding fix out for CentOS Linux 8
> and CentOS Stream 8.  No one is happy about how much longer this
> particular update is taking.  The Stream model brings massive changes
> to the RHEL workflows, so no one should be surprised that there are
> growing pains.
>
> On Mon, Jul 26, 2021 at 4:02 PM Steven Rosenberg via CentOS
>  wrote:
>
>>
>> This bug in the kernel was patched in RHEL on 7/20. Every other mainstream 
>> Linux distro patched it that day or the day after. That includes Rocky and 
>> Alma.
>>
>> https://access.redhat.com/security/cve/CVE-2021-33909
>>
>> It's still not patched six days later in CentOS Stream 8.
>>
>> This Bugzilla entry makes it clear that when it comes to security, CentOS 
>> Stream falls behind RHEL. But this far behind?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1975182
>>
>> This doesn't make a good argument for Stream being a viable CentOS Linux 
>> replacement.
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
> -- 
> Carl George
>

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] It's been six days since CVD-2021-33909 was patched in RHEL, what's the holdup for Stream 8?

[Carl George]

It's being worked on.  RHEL maintainers can fix things independently
in different minor version branches.  The fix was applied to the
internal 8.4 branch while it was under embargo.  It has since been
released in RHEL 8.4, which allowed it to be rebuilt in CentOS Linux
8.  CentOS Stream 8 is currently tracking the internal 8.5 branch,
which just had the fix merged yesterday, along with many other
changes, as kernel-4.18.0-326.el8.  That build is going through QA
now.  Once completed, it will be exported to git.centos.org and
rebuilt in CentOS Stream 8.  This is the "inside out" process we've
referred to, and we know it's not ideal.  CentOS Stream 9 improves on
this significantly with RHEL maintainers doing their builds directly
in the CentOS project, in the public.

I'll also note this isn't something new.  We've been clear that RHEL
gets some security fixes first.  Typically it's only 1-2 days after
RHEL 8 that we'll have the corresponding fix out for CentOS Linux 8
and CentOS Stream 8.  No one is happy about how much longer this
particular update is taking.  The Stream model brings massive changes
to the RHEL workflows, so no one should be surprised that there are
growing pains.

On Mon, Jul 26, 2021 at 4:02 PM Steven Rosenberg via CentOS
 wrote:
>
> This bug in the kernel was patched in RHEL on 7/20. Every other mainstream 
> Linux distro patched it that day or the day after. That includes Rocky and 
> Alma.
>
> https://access.redhat.com/security/cve/CVE-2021-33909
>
> It's still not patched six days later in CentOS Stream 8.
>
> This Bugzilla entry makes it clear that when it comes to security, CentOS 
> Stream falls behind RHEL. But this far behind?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1975182
>
> This doesn't make a good argument for Stream being a viable CentOS Linux 
> replacement.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Carl George

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] VzLinux - Opinions? Thoughs, Comments? - no microsoft involvement/contamination

[Jonathan Billings]

On Wed, Jul 28, 2021 at 08:56:29AM -0400, mario juliano grande-balletta wrote:
>
> Anyone using or working with VzLinux, seems to be an upstream distro of
> CentOS/RHEL and no vendors involved
> Would love to hear experiences.
> thanks!

Please start a new thread rather than replying to an existing thread,
thanks!

For what its worth, I'm not sure what you mean in your subject about
Microsoft involvement/contamination.  What does that have to do with
anything? 

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] VzLinux - Opinions? Thoughs, Comments? - no microsoft involvement/contamination

[Jonathan Billings]

On Wed, Jul 28, 2021 at 09:16:48AM -0500, Jon Pruente wrote:
> No vendors? It's the product of a single vendor, the long running Linux
> hypervisor platform creator Virtuozzo. They made it to run on their OpenVZ
> hypervisor platform.
> 
> https://www.virtuozzo.com/product-updates/virtuozzo-vzlinux-8-4-now-available/

And it does appear to be downstream from RHEL, another rebuild like
Alma, Rocky, Springdale, etc.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] VzLinux - Opinions? Thoughs, Comments? - no microsoft involvement/contamination

[mario juliano grande-balletta]

Thanks John!  Appreciate it.
a co-worker uploaded an appliance into customer vCenter and it was
VzLinux, never saw it or heard of it before, didn't have time to
research, just thought I would ask the group here for a quick answer,
thanks!

On Wed, 2021-07-28 at 09:16 -0500, Jon Pruente wrote:
> On Wed, Jul 28, 2021 at 7:56 AM mario juliano grande-balletta <
> mario.balle...@gmail.com> wrote:
> Anyone using or working with VzLinux, seems to be an upstream distro
> ofCentOS/RHEL and no vendors involvedWould love to hear
> experiences.thanks!:-)
> 
> No vendors? It's the product of a single vendor, the long running
> Linuxhypervisor platform creator Virtuozzo. They made it to run on
> their OpenVZhypervisor platform.
> 
https://www.virtuozzo.com/product-updates/virtuozzo-vzlinux-8-4-now-available/___CentOS
>  mailing listcen...@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] VzLinux - Opinions? Thoughs, Comments? - no microsoft involvement/contamination

[Jon Pruente]

On Wed, Jul 28, 2021 at 7:56 AM mario juliano grande-balletta <
mario.balle...@gmail.com> wrote:

> Anyone using or working with VzLinux, seems to be an upstream distro of
> CentOS/RHEL and no vendors involved
> Would love to hear experiences.
> thanks!
> :-)
>

No vendors? It's the product of a single vendor, the long running Linux
hypervisor platform creator Virtuozzo. They made it to run on their OpenVZ
hypervisor platform.

https://www.virtuozzo.com/product-updates/virtuozzo-vzlinux-8-4-now-available/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] hosts.deny, fail2ban etc.

[Leon Fauster via CentOS]

On 28.07.21 14:44, Jonathan Billings wrote:

On Jul 27, 2021, at 16:43, H  wrote:


|Running CentOS 7. I was under the impression - seemingly mistaken - that by 
adding a rule to /etc/hosts.deny such as ALL: aaa.bbb.ccc.* would ban all 
attempts from that network segment to connect to the server, ie before fail2ban 
would (eventually) ban connection attempts.

This, however, does not seem correct and I could use a pointer to correct my 
misunderstanding. How is hosts.deny used and what have I missed?

Is it necessary to run:

  iptables -I INPUT -s aaa.bbb.ccc.0/24 -j DROP

to drop incoming connection attempts from that subnet?


Upstream openssh dropped support for tcp wrappers (hosts.deny) a while ago but 
RHEL had patched support back in for a while, but I believe it isn’t supported 
anymore.

For what it’s worth, if you use the fail2ban-firewalld package, it uses ipset 
rather than iptables, which is more efficient.




TCP wrappers (hosts.allow/deny) are deprecated now.

Its still supported in EL7 (sshd example)

ldd /usr/sbin/sshd |grep wrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x7fcc483ee000)

but not in EL8 anymore. EL8 is based on F28/29 ->
  https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers

For the question above (for EL7):
only services that are compiled against libwrap uses hosts.deny
everything else will be reachable (if iptables does not drop it).

For EL8, as depicted in the above URI:
systemd provide a similar functionality ...

--
Leon




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] VzLinux - Opinions? Thoughs, Comments? - no microsoft involvement/contamination

[mario juliano grande-balletta]

Anyone using or working with VzLinux, seems to be an upstream distro of
CentOS/RHEL and no vendors involved
Would love to hear experiences.
thanks!
:-)




On Wed, 2021-07-28 at 08:49 -0400, Jonathan Billings wrote:
> On Jul 28, 2021, at 08:44, Jonathan Billings 
> wrote:
> 
> For what it’s worth, if you use the fail2ban-firewalld package, it
> uses ipset rather than iptables, which is more efficient. 
> That’s in CentOS 7 though. CentOS 8 firewalld uses nft instead of the
> older netfilter (iptables/ipset) code. 
> --Jonathan
> Billings___CentOS mailing
> listCentOS@centos.orghttps://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] hosts.deny, fail2ban etc.

[Jonathan Billings]

On Jul 28, 2021, at 08:44, Jonathan Billings  wrote:
> 
> For what it’s worth, if you use the fail2ban-firewalld package, it uses ipset 
> rather than iptables, which is more efficient. 

That’s in CentOS 7 though. CentOS 8 firewalld uses nft instead of the older 
netfilter (iptables/ipset) code. 

--
Jonathan Billings
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] hosts.deny, fail2ban etc.

[Jonathan Billings]

On Jul 27, 2021, at 16:43, H  wrote:
> 
> |Running CentOS 7. I was under the impression - seemingly mistaken - that by 
> adding a rule to /etc/hosts.deny such as ALL: aaa.bbb.ccc.* would ban all 
> attempts from that network segment to connect to the server, ie before 
> fail2ban would (eventually) ban connection attempts.
> 
> This, however, does not seem correct and I could use a pointer to correct my 
> misunderstanding. How is hosts.deny used and what have I missed?
> 
> Is it necessary to run:
> 
>  iptables -I INPUT -s aaa.bbb.ccc.0/24 -j DROP
> 
> to drop incoming connection attempts from that subnet?

Upstream openssh dropped support for tcp wrappers (hosts.deny) a while ago but 
RHEL had patched support back in for a while, but I believe it isn’t supported 
anymore. 

For what it’s worth, if you use the fail2ban-firewalld package, it uses ipset 
rather than iptables, which is more efficient.  

--
Jonathan Billings
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Old CentOS 6.3 grub.conf

[Jerry Geis]

I am trying to "add" an entry to grub.conf on CentOS 6.3 - and change the
default=0 to default=1

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#  all kernel and initrd paths are relative to /, eg.
#  root (hd0,0)
#  kernel /boot/vmlinuz-version ro root=/dev/sda1
#  initrd /boot/initrd-[generic-]version.img
#boot=/dev/sda
default=1
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.32-279.el6.x86_64)
  root (hd0,0)
  kernel /boot/vmlinuz-2.6.32-279.el6.x86_64 ro
root=UUID=09337d96-de39-43f1-99c2-8a6a1fadd465 rd_NO_LUKS rd_NO_LVM
LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto
 KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /boot/initramfs-2.6.32-279.el6.x86_64.img
title Boot Other
root (hd0,0)
kernel /boot/vmlinuz
initrd /boot/initrd


I then run "grub-install /dev/sda" and reboot.  If I cursor down - my new
title is present - but the default is still the first title.

What did I miss ?
Thanks,

jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] hosts.deny, fail2ban etc.

[Stephen John Smoogen]

On Tue, 27 Jul 2021 at 17:17, Pete Biggs  wrote:
>
> On Tue, 2021-07-27 at 16:43 -0400, H wrote:
> > > Running CentOS 7. I was under the impression - seemingly mistaken -
> > > that by adding a rule to /etc/hosts.deny such as ALL: aaa.bbb.ccc.*
> > > would ban all attempts from that network segment to connect to the
> > > server, ie before fail2ban would (eventually) ban connection
> > > attempts.
> >
> > This, however, does not seem correct and I could use a pointer to
> > correct my misunderstanding. How is hosts.deny used and what have I
> > missed?
>
> hosts.deny is only used by specific programs that use TCP wrappers. It
> is not a general "deny this host access".
>
> Also note that fail2ban operates on individual hosts, not subnets.
>

[I should have waited and read all my email before responding. Peter
covered parts I did not.]


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] hosts.deny, fail2ban etc.

[Stephen John Smoogen]

On Tue, 27 Jul 2021 at 16:43, H  wrote:
>
> |Running CentOS 7. I was under the impression - seemingly mistaken - that by 
> adding a rule to /etc/hosts.deny such as ALL: aaa.bbb.ccc.* would ban all 
> attempts from that network segment to connect to the server, ie before 
> fail2ban would (eventually) ban connection attempts.
>
> This, however, does not seem correct and I could use a pointer to correct my 
> misunderstanding. How is hosts.deny used and what have I missed?
>
> Is it necessary to run:
>
>  iptables -I INPUT -s aaa.bbb.ccc.0/24 -j DROP
>

yes. iptables is one of the first things which will see the packets
coming to the server as it is implemented in kernel space. hosts.deny
only comes in for specific services which are compiled to use it.

[Internet] <-> [iptables] <-> [systemd if used] <-> [xinetd w/tcp-wrappers]

In the above example, a packet coming from the internet gets
interpreted and dealt with multiple tools and hosts.deny is only used
in the last section where xinetd and similar programs compiled with
tcp-wrappers look at hosts.deny file.


> to drop incoming connection attempts from that subnet?
>
> Thank you!
> |
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos