date:20140320

On Thu, Mar 20, 2014 at 04:15:18PM -0600, Stephen John Smoogen wrote:
 I have been thinking about this and wondering if SCL's might be better
 under Robyn's EPIC (Extra Packages for Infrastructure and Clouds) which
 would be something that could have less rigid rules for keeping going for
 12 years that would be more in line with SCL's 2-3 year lifetimes. I was
 going to bring it up as a FLOCK talk to get the ball running with possible
 interaction with the CentOS group (maybe joining with their SCL
 operations). Does that make sense?

It makes a ton of sense to me, at least.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL and SCL

2014-03-20 Thread Karsten Wade

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/20/2014 05:30 PM, Dennis Jacobfeuerborn wrote:
 I've never heard of this EPIC repository and google doesn't seem to
 know it either. Where can this be found?

It doesn't exist, it's an idea that Robyn has floated semi-seriously
as a way to provide a repo that moves faster than EPEL. Rather than
try to jam fast-moving stuff in to EPEL, the idea was to do an Extra
Packages for Infrastructure and Cloud (EPIC) that had a different,
faster-moving charter. EPIC would target the *EL platform just as EPEL
does.

For the record, *I* think EPIC is an epic name.

- - Karsten
- -- 
Karsten 'quaid' Wade.^\  CentOS Doer of Stuff
http://TheOpenSourceWay.org\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v' gpg: AD0E0C41
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMrl2oACgkQ2ZIOBq0ODEH7kQCggq4gnXeYjG5xich1BLbkRwZh
KT4An2qmT0p6XO99pMXuFCeQCgsnj/r7
=X822
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Yet another bug caused by SELinux

2014-03-20 Thread Kevin Kofler

Hi,

GHC (Haskell) was broken for (at least) over a year because of a bug in the 
workaround for stupid SELinux restrictions:
https://ghc.haskell.org/trac/ghc/ticket/7629
https://bugzilla.redhat.com/show_bug.cgi?id=907515

How much breakage will we have to suffer until people finally realize that 
SELinux is a horribly flawed idea?

Kevin Kofler

PS: Et ceterum censeo SELinux esse delendum.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: GCJ [was: pdftk retired?]

2014-03-20 Thread Andrew Haley

On 03/19/2014 10:59 PM, Andrew Hughes wrote:
 - Original Message -
 On 03/08/2014 03:37 AM, Orcan Ogetbil wrote:
 On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote:

 Sorry I am missing something. Why can't we keep the old pdftk that
 works with itext2?

 Check the whole thread - because of GCJ dependency. iText is second
 issue. The first could be fixed by rewrite of offending part of code
 to Java but someone would have to do it first. That's how I understand
 this situation.


 The only things I read in the thread are GCJ is abandoned and we
 really want to get rid of GCJ. Am I supposed to come to the
 conclusion that the GCJ package is dropped from Fedora? If so, where
 is this decision made? Why was it made without consulting GCJ users?

 The problem is more to do with upstream maintainership.  If GCJ is to
 be used in the future it needs to be updated to a current version of
 the Java class library, but that's a lot of work.  GCJ is still a
 pretty good compiler for the Java language, but it's stuck at JDK5
 (ish).
 
 And JDK5 might be good enough for the use required. It doesn't claim
 to be anything more than that, so I don't see the harm in leaving it there.

Speaking as the upstream maintainer, I do.

Andrew.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Yet another bug caused by SELinux

2014-03-20 Thread H . Guémar

2014-03-20 12:22 GMT+01:00 Kevin Kofler kevin.kof...@chello.at:
 Hi,

 GHC (Haskell) was broken for (at least) over a year because of a bug in the
 workaround for stupid SELinux restrictions:
 https://ghc.haskell.org/trac/ghc/ticket/7629
 https://bugzilla.redhat.com/show_bug.cgi?id=907515

 How much breakage will we have to suffer until people finally realize that
 SELinux is a horribly flawed idea?

 Kevin Kofler

 PS: Et ceterum censeo SELinux esse delendum.

Hi,

according to the RHBZ ticket, there was a fix but it was not timely
applied to the package.
Rather than SELinux, I'd say that the fault lies with the crazy
updates policy that plague us.

regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

2014-03-20 Thread Bastien Nocera

- Original Message -
 Workstation might implement easy installation of alternative desktops in
 the GNOME Software app at some point.

Urgh. This is just moving the problem from the installer/media selection to the
software installer. Just what would we gain by doing that given that there will
still be other desktops in the repos, and other spins?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fail2ban + firewalld suggestions needed

2014-03-20 Thread Richard Shaw

On Wed, Mar 19, 2014 at 10:57 PM, Orion Poplawski or...@cora.nwra.comwrote:

 On 03/19/2014 09:10 PM, Richard Shaw wrote:
  Ok using Jonathan's suggestion for the settings from a clean install I'm
  getting an error whether I use the systemd backend or not...
 
 [12698]: ERROR   ipset
  create fail2ban-sshd hash:ip timeout 600
  firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport
  --dports ssh -m set --match-set fail2ban-sshd src -j REJECT
  --reject-with icmp-port-unreachable -- stderr: '/bin/sh: ipset: command
  not found\n'


 Currently we're missing a requires on ipset.



Ok, is installing ipset sufficient or do I need to enable the service as
well?

Thanks,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1052192] perl-IO-Socket-IP-0.25 is available

2014-03-20 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1052192

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-IO-Socket-IP-0.26-1.fc
   ||20
 Resolution|--- |CURRENTRELEASE
Last Closed||2014-03-20 09:04:37



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=6KezxlYnQXa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: fail2ban + firewalld suggestions needed

2014-03-20 Thread Jonathan Underwood

On 20 March 2014 13:04, Richard Shaw hobbes1...@gmail.com wrote:
 On Wed, Mar 19, 2014 at 10:57 PM, Orion Poplawski or...@cora.nwra.com
 wrote:

 On 03/19/2014 09:10 PM, Richard Shaw wrote:
  Ok using Jonathan's suggestion for the settings from a clean install I'm
  getting an error whether I use the systemd backend or not...
 
 [12698]: ERROR   ipset
  create fail2ban-sshd hash:ip timeout 600
  firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport
  --dports ssh -m set --match-set fail2ban-sshd src -j REJECT
  --reject-with icmp-port-unreachable -- stderr: '/bin/sh: ipset: command
  not found\n'


 Currently we're missing a requires on ipset.



 Ok, is installing ipset sufficient or do I need to enable the service as
 well?

Installing ipset should be sufficient to start the fail2ban service.
But, you'll need to have selinux-policy-3.12.1-135 or later installed,
otherwise you'll hit this:

https://bugzilla.redhat.com/show_bug.cgi?id=1069640
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Strange ssh / openldap linking problem

2014-03-20 Thread Richard W.M. Jones

Well this bug has reappeared on my machine.  openldap depends on
openldap-devel.

$ ll /usr/lib64/libldap*
lrwxrwxrwx. 1 root root 10 Feb 25 22:59 /usr/lib64/libldap-2.4.so.2 - 
libldap.so
-rwxr-xr-x. 1 root root 340608 Feb  4 09:08 /usr/lib64/libldap-2.4.so.2.10.2
lrwxrwxrwx. 1 root root 12 Feb 25 22:59 /usr/lib64/libldap_r-2.4.so.2 - 
libldap_r.so
-rwxr-xr-x. 1 root root 365848 Feb  4 09:08 /usr/lib64/libldap_r-2.4.so.2.10.2
lrwxrwxrwx. 1 root root 23 Feb 25 23:09 /usr/lib64/libldap_r.so - 
libldap_r-2.4.so.2.10.2
lrwxrwxrwx. 1 root root 21 Feb 25 23:09 /usr/lib64/libldap.so - 
libldap-2.4.so.2.10.2

$ for f in /usr/lib64/libldap*; do echo -n $f comes from ; rpm -qf $f; done
/usr/lib64/libldap-2.4.so.2 comes from openldap-2.4.39-2.fc20.x86_64
/usr/lib64/libldap-2.4.so.2.10.2 comes from openldap-2.4.39-2.fc20.x86_64
/usr/lib64/libldap_r-2.4.so.2 comes from openldap-2.4.39-2.fc20.x86_64
/usr/lib64/libldap_r-2.4.so.2.10.2 comes from openldap-2.4.39-2.fc20.x86_64
/usr/lib64/libldap_r.so comes from openldap-devel-2.4.39-2.fc20.x86_64
/usr/lib64/libldap.so comes from openldap-devel-2.4.39-2.fc20.x86_64

This breaks libguestfs when it happens.

I've noticed that lots of people have hit this bug before:

https://bugzilla.redhat.com/show_bug.cgi?id=240253
https://bugzilla.redhat.com/show_bug.cgi?id=248065
https://bugzilla.redhat.com/show_bug.cgi?id=249866
https://bugzilla.redhat.com/show_bug.cgi?id=447645
https://bugzilla.redhat.com/show_bug.cgi?id=460307
https://bugzilla.redhat.com/show_bug.cgi?id=693716
https://bugzilla.redhat.com/show_bug.cgi?id=1028557

It's obviously a longstanding packaging bug in openldap and I think it
needs to be fixed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fail2ban + firewalld suggestions needed

2014-03-20 Thread Przemek Klosowski


On 03/20/2014 12:24 AM, Orion Poplawski wrote:

On 03/19/2014 02:56 PM, Matthew Miller wrote:

On Wed, Mar 19, 2014 at 02:32:40PM -0600, Orion Poplawski wrote:

Hmm, I like this alternative a lot.  I'm probably taking this too
far, but I'm thinking of:

fail2ban-server - core components with minimal deps

fail2ban-firewalld - firewalld support/configuration - requires firewalld
fail2ban-hostsdeny - tcp_wrappers hosts.deny support - requires tcp_wrappers
fail2ban-mail  - mail actions- requires /usr/bin/mail
fail2ban-sendmail  - sendmail actions- requires 
/usr/sbin/sendmail
fail2ban-shorewall - shorewall support   - requires shorewall
fail2ban-systemd   - systemd journal configuration

fail2ban - default component - installs -firewalld,-sendmail,-systemd
fail2ban-all - installs everything - also requires /usr/bin/whois

Comments?

That _might_ be going overboard. But it certainly does allow a lot of
flexibility. Somewhere there is a balance between that flexibility and the
extra packaging work and potential user confusion, and I'm not exactly sure
where that line is in this case. :)

This seemed reasonable to me so I've gone with it in rawhide now.
Testing welcome.



I am concerned that this looks like configuring the fail2ban package by 
installing more packages. If we started doing it everywhere multiple 
packages interact, it would combinatorially explode  the number of 
packages and make the system harder to maintain, not easier. Among other 
things, it would make managing the subsystem on Fedora different than 
everywhere else including upstream.


It's certainly a neat trick (down with obscure config files!), but the 
approach does not scale. Taking this to extreme, we'd be doing yum 
install emacs-vim-mode.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fail2ban + firewalld suggestions needed

2014-03-20 Thread Jonathan Underwood

On 20 March 2014 16:17, Przemek Klosowski przemek.klosow...@nist.gov wrote:
 I am concerned that this looks like configuring the fail2ban package by
 installing more packages. If we started doing it everywhere multiple
 packages interact, it would combinatorially explode  the number of packages
 and make the system harder to maintain, not easier. Among other things, it
 would make managing the subsystem on Fedora different than everywhere else
 including upstream.

I tend to agree here - personally I think one sensible default
configuration is sufficient, and then let users adjust/taylor that
configuration for their needs. RPM is the wrong layer for
configuration management IMO - this also pertains to the recent
discussions  regarding diverging configs for the different projects.
RPM should lay down files, and then a proper config management service
should configure/customise software (Puppet,ansible, what have you).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

2014-03-20 Thread Przemek Klosowski


On 03/20/2014 01:21 AM, Chris Murphy wrote:

On Mar 19, 2014, at 7:51 PM, Adam Williamson awill...@redhat.com wrote:


On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:

More complex than trying to mirror a FAT ESP partition across multiple
boot disks, keeping it properly synchronized, because RAID isn't
supported?

You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
of how RAID-1 works; each individual member can also be mounted as if it
was just a plain old partition, which is how the firmware will mount it.

This shouldn't be done. It's a source of corruption to treat an md raid1 device 
as a plain volume, rather than as a degraded md device. If the plain partition 
volume is modified, its mdadm metadata won't be updated, so when the array is 
finally assembled, mdadm has no idea member devices are not sync'd, and also 
has no way to resolve the ambiguity.
Right, but UEFI doesn't write to itit just uses them to read the 
boot content. It would be better if UEFI could read software raid1 even 
if it was  degraded due to disk failures, but apparently it can't, so 
Adam's scheme is the only possibility.


I agree with you that nothing else but UEFI should mount those devices 
as  individual plain volumes, of course.


Because of this, at least one raid stack kernel maintainer wants to do away 
with the use of mdadm metadata v 1.0 by anaconda. It's v1.0 metadata that 
permits this plain old  partition treatment as a side effect.
It is a darn useful side effect. How else can you implement redundant 
boot that is transparently updated? I could (and did) try
multiple /boot partitions on separate drives by copying the partition 
content after updates, but it was fragile and I was never confident that 
it would work when I needed it. Adam's raid1 /boot just seems more 
reliable, especially if it became a designed feature.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

2014-03-20 Thread Andrew Lutomirski

On Thu, Mar 20, 2014 at 9:32 AM, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
 On 03/20/2014 01:21 AM, Chris Murphy wrote:
 You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
 of how RAID-1 works; each individual member can also be mounted as if it
 was just a plain old partition, which is how the firmware will mount it.

 This shouldn't be done. It's a source of corruption to treat an md raid1
 device as a plain volume, rather than as a degraded md device. If the plain
 partition volume is modified, its mdadm metadata won't be updated, so when
 the array is finally assembled, mdadm has no idea member devices are not
 sync'd, and also has no way to resolve the ambiguity.

 Right, but UEFI doesn't write to itit just uses them to read the boot
 content. It would be better if UEFI could read software raid1 even if it was
 degraded due to disk failures, but apparently it can't, so Adam's scheme is
 the only possibility.

Um.

EFI_FILE_PROTOCOL's Write method sounds suspiciously like it writes to
a filesystem.


 Because of this, at least one raid stack kernel maintainer wants to do away
 with the use of mdadm metadata v 1.0 by anaconda. It's v1.0 metadata that
 permits this plain old  partition treatment as a side effect.

 It is a darn useful side effect. How else can you implement redundant boot
 that is transparently updated? I could (and did) try
 multiple /boot partitions on separate drives by copying the partition
 content after updates, but it was fragile and I was never confident that it
 would work when I needed it. Adam's raid1 /boot just seems more reliable,
 especially if it became a designed feature.


I think you may be confusing /boot and ESP (aka /boot/efi).  They are
not the same thing.

You get a transparently updated list of kernels by doing it exactly
the way that Chris suggested.  You have /boot on md raid with metadata
1.1 or 1.2.  Or you have /boot on any other sensible RAID backing
store, where sensible means that everything that mounts it knows that
it's RAID.

Then you stick something *that never changes* into each copy of the
ESP.  And you don't even pretend that ESP is RAID -- it's simply a
bunch of FAT filesystems that *are not mounted read/write* except for
when the bootloader is reinstalled.  And you do *not* reinstall the
bootloader just because you have a new kernel.

All of the RAID devices are only ever accessed by RAID drivers.  All
of the ESP non-RAID filesystems are treated as the crappy FAT
filesystems that they are and are almost never written by Linux
userspace.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:

 Adam's scheme is the only possibility.

 Adam's raid1 /boot just seems more 
 reliable, especially if it became a designed feature.

It's not my plan, it's the anaconda developers'. I only described it.
Actually it took them like 15 minutes to get it into my dumb brain. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Wed, 2014-03-19 at 23:21 -0600, Chris Murphy wrote:

 Therefore I don't think software RAID is a solution.

Well, this is new: I'm fairly sure you were the one who filed a bug
requesting it in the first damn place.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 09:49 -0700, Andrew Lutomirski wrote:

 Um.
 
 EFI_FILE_PROTOCOL's Write method sounds suspiciously like it writes to
 a filesystem.

Sure, UEFI has the capability, but it's not going to be used when simply
booting the system normally. All the firmware does in that case is mount
the partition and execute the bootloader it finds there.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Yet another bug caused by SELinux

On Thu, 2014-03-20 at 12:35 +0100, H. Guémar wrote:
 2014-03-20 12:22 GMT+01:00 Kevin Kofler kevin.kof...@chello.at:
  Hi,
 
  GHC (Haskell) was broken for (at least) over a year because of a bug in the
  workaround for stupid SELinux restrictions:
  https://ghc.haskell.org/trac/ghc/ticket/7629
  https://bugzilla.redhat.com/show_bug.cgi?id=907515
 
  How much breakage will we have to suffer until people finally realize that
  SELinux is a horribly flawed idea?
 
  Kevin Kofler
 
  PS: Et ceterum censeo SELinux esse delendum.
 
 Hi,
 
 according to the RHBZ ticket, there was a fix but it was not timely
 applied to the package.
 Rather than SELinux, I'd say that the fault lies with the crazy
 updates policy that plague us.

I don't know how you figure that. The update for F20 was submitted on
01-29 and pushed stable on 02-17. For F19 it was submitted 01-29 and
pushed stable on 03-19. Both updates could have been pushed stable as
early as 02-06: as ghc is not a critpath package, the update policy
requires only a 7 day wait unless karma is posted.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

2014-03-20 Thread Andrew Lutomirski

On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:

 Adam's scheme is the only possibility.

 Adam's raid1 /boot just seems more
 reliable, especially if it became a designed feature.

 It's not my plan, it's the anaconda developers'. I only described it.
 Actually it took them like 15 minutes to get it into my dumb brain. :)

Can you all please try to make sure you're talking about the same thing?

I believe that Chris is suggesting /boot as raid1 and ESP not mounted.

Adam and Przemek seem to be talking about /boot on RAID1 (I've never
heard anyone say that /boot as RAID is a bad idea) but I think
something's very confused about my understanding of your opinions
about how the ESP should or does work.  Can one or both of you please
describe, unambiguously, how you think the ESP should be created, when
and if it should be mounted, what filesystem and/or raid config should
be used to mount it, and what should happen when a kernel is updated?

 Sure, UEFI has the capability, but it's not going to be used when simply
 booting the system normally. All the firmware does in that case is mount
 the partition and execute the bootloader it finds there.

Why not?  It's completely safe when the OS is Mac OS or Windows.  It's
sometimes safe when the OS is Linux.  It's even possibly useful: you
might want to have an ESP bootloader, shim, or whatever that logs
errors.  I bet there's at least one UEFI firmware out there that backs
up settings to ESP and/or backs up a whole firmware image to ESP.

It would be a shame for a Linux RAID install to corrupt the ESP just
because you did something unusual in various UEFI menus.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Yet another bug caused by SELinux

On Thu, 2014-03-20 at 12:22 +0100, Kevin Kofler wrote:
 Hi,
 
 GHC (Haskell) was broken for (at least) over a year because of a bug in the 
 workaround for stupid SELinux restrictions:
 https://ghc.haskell.org/trac/ghc/ticket/7629
 https://bugzilla.redhat.com/show_bug.cgi?id=907515
 
 How much breakage will we have to suffer until people finally realize that 
 SELinux is a horribly flawed idea?

Of course restrictions implemented for security reasons will cause
issues. I don't know why you keep posting cases and acting as if this
will be news to someone. They happen, we get them fixed, everyone's
lives improve.

On the timeline of this one: as I read the reports, it was reported to
upstream on 2013-01-25. It was reported to Fedora on 2013-02-04. The
reporter tracked down and fixed the issue upstream on 2013-03-26. So one
month and 22 days after it was reported to Fedora, a patch was available
and could have been backported. In fact the patch was only backported to
Fedora 19 on 2014-01-29. The delay from 2013-03-26 to 2014-01-29 was the
Fedora maintainer's. Not to throw stones - maintainers are all busy -
just to note the facts: this issue could have been resolved much faster,
and SELinux is not the reason why it wasn't.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

2014-03-20 Thread Andrew Lutomirski

On Thu, Mar 20, 2014 at 10:07 AM, Andrew Lutomirski l...@mit.edu wrote:
 On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson awill...@redhat.com wrote:
 Sure, UEFI has the capability, but it's not going to be used when simply
 booting the system normally. All the firmware does in that case is mount
 the partition and execute the bootloader it finds there.

 Why not?  It's completely safe when the OS is Mac OS or Windows.  It's
 sometimes safe when the OS is Linux.  It's even possibly useful: you
 might want to have an ESP bootloader, shim, or whatever that logs
 errors.  I bet there's at least one UEFI firmware out there that backs
 up settings to ESP and/or backs up a whole firmware image to ESP.

 It would be a shame for a Linux RAID install to corrupt the ESP just
 because you did something unusual in various UEFI menus.

The standard EFI Shell can do exactly this.  It has commands like
'edit' and 'mkdir'.  I think that using them should not cause
filesystem corruption.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Maybe it's time to get rid of tcpwrappers/tcpd?

Heya!

I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora. There has been a request in systemd upstream to disable support
for it by default, but I am not sure I want to do that unless we can
maybe say goodbye to it for the big picture too.

Why would we get rid of them? 

Well, to make things simpler, primarily. They have not seen any
development since 2003 (that's 11 years I mind you, an eternity in IT).

I doubt there are many people even using them anymore, firewalls are
more comprehensive and a lot more powerful, and while every admin knows
firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
actively make use of them...

The API is awful, too, with lot's of open-coded structures, feature
checks in the headers, fixed length strings, globally exported variables,
non-namespaced symbols, really weird exported compatibility wrappers for
OS calls...

I'd propose we make a clear cut, and just start disabling it in all
services that link to it, instead of letting rot on in Fedora for all
eternity.

It's bad code, little used, crufty. We have much better stuff now, and
that enables us to say goodbye to the old mess...

I figure there will be a bit of opposition to this change, thus I
thought I start the discussion on the fedora ML first. Unless there are
major concerns I will propose a feature about this in the next few
days. If somebody wants to join me on this and put his name on the
feature proposal I'd be delighted!

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 10:07 -0700, Andrew Lutomirski wrote:
 On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson awill...@redhat.com wrote:
  On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:
 
  Adam's scheme is the only possibility.
 
  Adam's raid1 /boot just seems more
  reliable, especially if it became a designed feature.
 
  It's not my plan, it's the anaconda developers'. I only described it.
  Actually it took them like 15 minutes to get it into my dumb brain. :)
 
 Can you all please try to make sure you're talking about the same thing?

 I believe that Chris is suggesting /boot as raid1 and ESP not mounted.

He is also giving feedback on the ESP-as-RAID1 idea. He's both doing
that *and* proposing an alternative, which may be what you're missing. I
don't think anyone but you is confused about the alternative ideas here.

 Adam and Przemek seem to be talking about /boot on RAID1 (I've never
 heard anyone say that /boot as RAID is a bad idea) but I think
 something's very confused about my understanding of your opinions
 about how the ESP should or does work.  Can one or both of you please
 describe, unambiguously, how you think the ESP should be created, when
 and if it should be mounted, what filesystem and/or raid config should
 be used to mount it, and what should happen when a kernel is updated?

I thought I already did. Just go back and read my original mail again.
And again, it's nothing about what I think, I was simply describing a
potential design which had been explained to me by someone else.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

EPEL and SCL

2014-03-20 Thread Remi Collet

Hi,

RHSCL 1.0 is GA since September.

RHSCL 1.1 Beta is released today:
http://developerblog.redhat.com/2014/03/20/rhscl-1-1-beta-available-apache-mongodb/

As EPEL is the common repository to find additional packages for RHEL, I
really think it should also be possible to provide additional packages
for RHSCL.

For now the Fedora Guidelines are still under discussion.

Most of the discussion is about the tree layout (/var, /etc/, ...).
This Guidelines will probably need more work/time before approval :(

Of course, if some new SCL (new, as not in upstream product) will come
to EPEL, it will have to follow the same Guidelines.

But, for additional packages for existing collections (I mean extending
RHSCL), thinks can be simpler. We only have to use the tree as defined
in the RHSCL collection (in the meta-package).

I really hope we can find some solution.

Of course, we need to ensure, with rel-eng, that we are able to build
those packages.


So, time to raise the discussion.


Remi.


P.S. you will notice that whatever we decide, things will happen (and
have already start), we just need to know if we want to see this in EPEL
or outside.
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

2014-03-20 Thread Chris Murphy


On Mar 20, 2014, at 10:32 AM, Przemek Klosowski przemek.klosow...@nist.gov 
wrote:

 It is a darn useful side effect. How else can you implement redundant boot 
 that is transparently updated?

For /boot, rather than /boot/efi, use metadata v1.2 and a bootloader that 
understands v1.2 metadata. GRUB2 has for some time.


Chris Murphy

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Paul Wouters


On Thu, 20 Mar 2014, Lennart Poettering wrote:


I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora.


I'd be happy to see those go.

Those who depend on it though, should see some failed closed
behaviour, so their service does not suddenly become more exposed.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Erinn Looney-Triggs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/20/2014 11:59 AM, Paul Wouters wrote:
 On Thu, 20 Mar 2014, Lennart Poettering wrote:
 
 I wonder whether it wouldn't be time to say goodbye to
 tcpwrappers in Fedora.
 
 I'd be happy to see those go.
 
 Those who depend on it though, should see some failed closed 
 behaviour, so their service does not suddenly become more exposed.
 
 Paul

Yeah I am not sure you are going to be able to make a totally clean
cut, there are some of us out there who still use this and it works,
despite however much crap it is underneath the covers.

A fail closed would be a decent first step, but as I said dropping it
altogether without some mitigation would be a bad move I believe.

Just my two cents,

- -Erinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJTKy9KAAoJEFg7BmJL2iPOqhgH/AxzMlqVHGn2p2GBHkVsvDCY
jjtA7/GDiWWHaOWykKIPFsxu+SiULux1JbcIop0qIsWsb8wbeQjrC/9tMIpRPb5n
Zsx3Zpk4YfWabEjSuhSjIYBqkbhh/5OQNYHLmeaTMR6rd8/N9MMrwlrxBjRtSLlG
ghxQ3BcqCdVR4hdFdBGkaTi1MXxjxcXVpcoOK/1vU63r9VeTz0UMGpC7heXA3d1O
4cuFY2D9zvu4y78UEC8RqM/p4pv3b6dAmNmatAilc4tiCUgQUt03n2K1TUVctsc0
zvDmx+bFeu6A8RnRNGddkvSKrv/qG96qKHucQ1tLCNvcZ1sdeLkMvurSeq+Pdkw=
=/0ol
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Stephen John Smoogen

On 20 March 2014 11:34, Lennart Poettering mzerq...@0pointer.de wrote:

 Heya!

 I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
 Fedora. There has been a request in systemd upstream to disable support
 for it by default, but I am not sure I want to do that unless we can
 maybe say goodbye to it for the big picture too.

 Why would we get rid of them?

 Well, to make things simpler, primarily. They have not seen any
 development since 2003 (that's 11 years I mind you, an eternity in IT).

 I doubt there are many people even using them anymore, firewalls are
 more comprehensive and a lot more powerful, and while every admin knows
 firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
 actively make use of them...


Actually they are used quite a bit in various service worlds. Mainly for
ssh and email for dealing with scanners. [DenyHosts is a boon in this
area.] The reason for using a secondary tool is that depth of security.
Over the years I have found that there are multiple of attacks which will
nullify one layer of protection at one point or another. Having a second
level or third level of protection is a boon when this happens.

At the enterprise level firewalls can come under a different set of change
control rules than something like tcpwrappers which is considered
application level. While I would like to be able to make a simple change in
a firewall, I can end up spending a month until I can. Application controls
are usually an hour or so signoff. This means that if tcp-wrappers is going
then something will need to be able to replace it to meet that large scale
concern. [Automatic firewall controls like firewalld have to be disabled or
put into a manual changes only mode in these areas for change control
purposes. ]

I can't argue on the code maintainability or layout. Not my area of
expertise. I can say that if tcpd/libtcpwrappers were to go away that
something equivalent would need to be built to replace it for the ability
to fine tune at a layer below the firewall.




 The API is awful, too, with lot's of open-coded structures, feature
 checks in the headers, fixed length strings, globally exported variables,
 non-namespaced symbols, really weird exported compatibility wrappers for
 OS calls...

 I'd propose we make a clear cut, and just start disabling it in all
 services that link to it, instead of letting rot on in Fedora for all
 eternity.

 It's bad code, little used, crufty. We have much better stuff now, and
 that enables us to say goodbye to the old mess...

 I figure there will be a bit of opposition to this change, thus I
 thought I start the discussion on the fedora ML first. Unless there are
 major concerns I will propose a feature about this in the next few
 days. If somebody wants to join me on this and put his name on the
 feature proposal I'd be delighted!

 Lennart

 --
 Lennart Poettering, Red Hat
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Martin Langhoff

On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerq...@0pointer.dewrote:

 I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
 Fedora. There has been a request in systemd upstream to disable support


As Stephen points out, they are used. Does systemd+xinetd match their
functionality?

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 13:59, Paul Wouters (p...@nohats.ca) wrote:

 Those who depend on it though, should see some failed closed
 behaviour, so their service does not suddenly become more exposed.

Well, this sounds like something to cover in the release notes, plus a
check in fedup or so that tells people about this should
/etc/hosts.{allow,deny} have changed from shipped defaults or so.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 14:31, Martin Langhoff (martin.langh...@gmail.com) wrote:

 On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering 
 mzerq...@0pointer.dewrote:
 
  I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
  Fedora. There has been a request in systemd upstream to disable support
 
 
 As Stephen points out, they are used. Does systemd+xinetd match their
 functionality?

No. systemd is not a firewall. It currently supports libwrap checks for
socket activated services. And I'd really like to get rid of that...

I have no doubt that some people use them, however I am also pretty sure
that they are massively awful, and not worth the trouble, and that I'd
prefer not to see this crap in the default install. However, since the
library is currently hooked into a lot of services (starting with
systemd itself) I currently cannot do rpm -e.

I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if
people want to make use of that. I am simply proposing to not link
agains them anymore for everything that is in the default system.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote:

  I doubt there are many people even using them anymore, firewalls are
  more comprehensive and a lot more powerful, and while every admin knows
  firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
  actively make use of them...
 
 
 Actually they are used quite a bit in various service worlds. Mainly for
 ssh and email for dealing with scanners. [DenyHosts is a boon in this
 area.] The reason for using a secondary tool is that depth of
 security.

Well, all mails servers as well as sshd have much better ways to do
such filtering. sshd has Match,  Postfix for example has
smtpd_client_restrictions=, and so on.

Again, I have no doubt that some people still use tcpwrappers. But I'd
argue that is clearly the excpetion, not the rule, and they'd better use
something different, and that we should be creating an excellent distro,
instead of a one that features horrible software...

 Over the years I have found that there are multiple of attacks which will
 nullify one layer of protection at one point or another. Having a second
 level or third level of protection is a boon when this happens.

Well, it certainly makes sense to combine a firewall with let's say
selinux with maybe postfix/ssh acls. Then you already have three layers
of protection, of very good protection. But of all possible options
tcpwrap is the absolute worst choice. And we should be able to deprecate
and remove stuff from our core OS if we think it is crap.

I mean, there are two sides of the medal: sure multiple layers of
protection might be a good thing, but you also make things a lot more
complex with each one, and you involve more possibly exploitable code --
and tcpwrap is simply bad code, that's a fact. So you have to balance
things out: is something a layer that is worth the trouble? Or does
having it around make things worse? I am of the opinion that tcpwrap
indeed does make things worse.

Sure, three layers of condoms probably make sex safer, but then again,
if one of them is made of 10 year old half-decomposed goat intestines,
then maybe the sex is a lot less fun, too...

 At the enterprise level firewalls can come under a different set of change
 control rules than something like tcpwrappers which is considered
 application level. While I would like to be able to make a simple change in
 a firewall, I can end up spending a month until I can. Application controls
 are usually an hour or so signoff. This means that if tcp-wrappers is going
 then something will need to be able to replace it to meet that large scale
 concern. [Automatic firewall controls like firewalld have to be disabled or
 put into a manual changes only mode in these areas for change control
 purposes. ]

Well, that really sounds like a specific issue of your
company... Really, I don't think the question whether the bureaucracy of
some hypothetical company makes a distinction between tcwrap and
firewalls has no place in the discussion whether we should support
tcpwrap in our distro or not.

 I can't argue on the code maintainability or layout. Not my area of
 expertise. I can say that if tcpd/libtcpwrappers were to go away that
 something equivalent would need to be built to replace it for the ability
 to fine tune at a layer below the firewall.

Why? Other than your hypothetical bureaucracy, is there anything that
tcpwrap can do that firewalls can't do, that really deserves to be
supported? I really can't see anything... [1]

tcpd comes from a time when there weren't local firewalls available in
all Unix systems, so they built something like them in userspace. But
that time is long long gone, and pretty much any Linux installation I
know nowadays has a firewall compiled into the kernel...

Lennart



[1] well, sure tcpwrap resolves DNS dynamically and can use that for
access control, but people who bind access control to DNS really should
find a different job than administrator...

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Florian Weimer

* Stephen John Smoogen:

 Actually they are used quite a bit in various service worlds. Mainly for
 ssh and email for dealing with scanners. [DenyHosts is a boon in this
 area.]

I believe DenyHosts is unmaintained as well:

  https://bugzilla.redhat.com/show_bug.cgi?id=1045983

 At the enterprise level firewalls can come under a different set of change
 control rules than something like tcpwrappers which is considered
 application level.

I think it's difficult to generalize in this area.  There is no
inherent reason why an iptables-based local packet filter has to
follow the same sign-off rules as a device on the forwarding path.

From my POV, it is kind of neat that you can grant access to *.enyo.de
and deny every thing else.  This is quite helpful against scanners and
worms, and programs like OpenSSH rely on tcpwrappers to implement
this.  It's not clear to me if this has to happen at the systemd
level, though.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fail2ban + firewalld suggestions needed

On Thu, Mar 20, 2014 at 12:17:46PM -0400, Przemek Klosowski wrote:
 fail2ban-server - core components with minimal deps
 fail2ban-firewalld - firewalld support/configuration - requires firewalld
 fail2ban-hostsdeny - tcp_wrappers hosts.deny support - requires 
 tcp_wrappers
 fail2ban-mail  - mail actions- requires 
 /usr/bin/mail
 fail2ban-sendmail  - sendmail actions- requires 
 /usr/sbin/sendmail
 fail2ban-shorewall - shorewall support   - requires shorewall
 fail2ban-systemd   - systemd journal configuration
 
 fail2ban - default component - installs -firewalld,-sendmail,-systemd
 fail2ban-all - installs everything - also requires /usr/bin/whois
 I am concerned that this looks like configuring the fail2ban package
 by installing more packages. If we started doing it everywhere

It looks like that, but the split is largely based on dependencies, and I
can see situations for each case where you might want to avoid pulling these
things in but still would want fail2ban. The systemd one is the exception,
because the journal isn't optional in Fedora. And I think I'd combine mail
and sendmail (because the /usr/sbin/sendmail command can be provided by a
lot of alternatives, including the very lightweight ssmtp).

And maybe hostsdeny should be part of the main server package, as it really
just manipulates /etc/hosts.deny, which is part of the mandatory 'setup'
package.


-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 20:06, Florian Weimer (f...@deneb.enyo.de) wrote:

* Stephen John Smoogen:

Actually they are used quite a bit in various service worlds. Mainly for
ssh and email for dealing with scanners. [DenyHosts is a boon in this
area.]

I believe DenyHosts is unmaintained as well:

https://bugzilla.redhat.com/show_bug.cgi?id=1045983

At the enterprise level firewalls can come under a different set of change
control rules than something like tcpwrappers which is considered
application level.

I think it's difficult to generalize in this area. There is no
inherent reason why an iptables-based local packet filter has to
follow the same sign-off rules as a device on the forwarding path.

From my POV, it is kind of neat that you can grant access to *.enyo.de
and deny every thing else.

Binding access control to DNS sounds insecure like hell..

This is quite helpful against scanners and
worms, and programs like OpenSSH rely on tcpwrappers to implement
this. It's not clear to me if this has to happen at the systemd
level, though.

OpenSSH can do this on its own without involving tcpwrap:

https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html

It sounds like a much better choice to stick to that instead of
involving tcpwrap, and we should push our users to understand that...

Lennart

--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Wed, 19.03.14 18:51, Adam Williamson (awill...@redhat.com) wrote:

  More complex than trying to mirror a FAT ESP partition across multiple
  boot disks, keeping it properly synchronized, because RAID isn't
  supported?
 
 You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
 of how RAID-1 works; each individual member can also be mounted as if it
 was just a plain old partition, which is how the firmware will mount it.
 The anaconda devs have thought about this, and are planning to implement
 it. On the UEFI side you just write entries for each of the ESPs into
 the EFI boot manager. If one of them fails, then the firmware will boot
 from the next in line.

I'd really stay away from doing anything RAID related with the ESP.

We really shouldn't have the same partition multiple times with the same
uuid and stuff. That is a call for trouble. 

This is a really awful idea. Really, things like the pre-kernel boot
logic should be kept simple, and what you are suggesting there is just
frickin' crazy.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Florian Weimer

* Lennart Poettering:

 From my POV, it is kind of neat that you can grant access to *.enyo.de
 and deny every thing else.  

 Binding access control to DNS sounds insecure like hell..

Additional restrictions are fine, for this purpose:

 This is quite helpful against scanners and worms,

(And with DNSSEC, it wouldn't be so insecure anymore, you don't even
need a secured reverse tree before it can be effective.)

 OpenSSH can do this on its own without involving tcpwrap:

 https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html

 It sounds like a much better choice to stick to that instead of
 involving tcpwrap, and we should push our users to understand that...

The nice thing about tcpwrappers is that it runs extremely early,
typically before any application code is exposed.  Something in the
guts of OpenSSH really isn't comparable.  It's not immediately obvious
how you'd block logins altogether.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 20:20 +0100, Lennart Poettering wrote:
 On Wed, 19.03.14 18:51, Adam Williamson (awill...@redhat.com) wrote:
 
   More complex than trying to mirror a FAT ESP partition across multiple
   boot disks, keeping it properly synchronized, because RAID isn't
   supported?
  
  You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
  of how RAID-1 works; each individual member can also be mounted as if it
  was just a plain old partition, which is how the firmware will mount it.
  The anaconda devs have thought about this, and are planning to implement
  it. On the UEFI side you just write entries for each of the ESPs into
  the EFI boot manager. If one of them fails, then the firmware will boot
  from the next in line.
 
 I'd really stay away from doing anything RAID related with the ESP.
 
 We really shouldn't have the same partition multiple times with the same
 uuid and stuff. That is a call for trouble. 
 
 This is a really awful idea. Really, things like the pre-kernel boot
 logic should be kept simple, and what you are suggesting there is just
 frickin' crazy.

Sigh, for the fourth time, I'm not suggesting it. It's not my idea. I'm
not going to defend it. I'm relaying a design that was outlined to me by
the anaconda devs. The motivation is that there have been multiple
requests to make it possible to have a redundant boot chain on native
UEFI installs, as you can on native BIOS installs.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Stephen John Smoogen

On 20 March 2014 13:05, Lennart Poettering mzerq...@0pointer.de wrote:

 On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote:

   I doubt there are many people even using them anymore, firewalls are
   more comprehensive and a lot more powerful, and while every admin knows
   firewalls, I figure only very few know tcpd/tcpwrap, and even fewer
 ever
   actively make use of them...
  
  
  Actually they are used quite a bit in various service worlds. Mainly for
  ssh and email for dealing with scanners. [DenyHosts is a boon in this
  area.] The reason for using a secondary tool is that depth of
  security.

 Well, all mails servers as well as sshd have much better ways to do
 such filtering. sshd has Match,  Postfix for example has
 smtpd_client_restrictions=, and so on.


And now I need to have X number applications special syntax to
whitelist/blacklist a site. I need to change X files to make that change.
Each of those could be a separate change control process depending on the
size of the organization. Or I have 1 file that I can make a change to
which has usually one syntax and one set of reviews.



 Again, I have no doubt that some people still use tcpwrappers. But I'd
 argue that is clearly the excpetion, not the rule, and they'd better use
 something different, and that we should be creating an excellent distro,
 instead of a one that features horrible software...


Look I am not saying it isn't horrible to look at from a coding side. From
a systems administrators side it does stuff in a very clean, easily audited
way. It is also a nice key place where every application is actually using
the same syntax versus each custom version. Having spent several ITIL
meetings where you have to explain the syntax of each application to
non-sysadmins, then prove that the change is correct, then prove that the
change is easily backed out, and then other parts.. having 1 syntax to do
that versus doing every applications custom version makes it a lot easier
to deal with.

I am not saying rip it out, but I am saying that you need something that
replaces that one syntax, one file control, simple syntax method.



  Over the years I have found that there are multiple of attacks which will
  nullify one layer of protection at one point or another. Having a second
  level or third level of protection is a boon when this happens.

 Well, it certainly makes sense to combine a firewall with let's say
 selinux with maybe postfix/ssh acls. Then you already have three layers
 of protection, of very good protection. But of all possible options
 tcpwrap is the absolute worst choice. And we should be able to deprecate
 and remove stuff from our core OS if we think it is crap.

 I mean, there are two sides of the medal: sure multiple layers of
 protection might be a good thing, but you also make things a lot more
 complex with each one, and you involve more possibly exploitable code --
 and tcpwrap is simply bad code, that's a fact. So you have to balance
 things out: is something a layer that is worth the trouble? Or does
 having it around make things worse? I am of the opinion that tcpwrap
 indeed does make things worse.

 Sure, three layers of condoms probably make sex safer, but then again,
 if one of them is made of 10 year old half-decomposed goat intestines,
 then maybe the sex is a lot less fun, too...


I don't see the need to make such crude references.



  At the enterprise level firewalls can come under a different set of
 change
  control rules than something like tcpwrappers which is considered
  application level. While I would like to be able to make a simple change
 in
  a firewall, I can end up spending a month until I can. Application
 controls
  are usually an hour or so signoff. This means that if tcp-wrappers is
 going
  then something will need to be able to replace it to meet that large
 scale
  concern. [Automatic firewall controls like firewalld have to be disabled
 or
  put into a manual changes only mode in these areas for change control
  purposes. ]

 Well, that really sounds like a specific issue of your
 company... Really, I don't think the question whether the bureaucracy of
 some hypothetical company makes a distinction between tcwrap and
 firewalls has no place in the discussion whether we should support
 tcpwrap in our distro or not.



I am giving you a standard enterprise problem. You are constantly going on
about how systemd solves enterprise level problems and enterprises will
love them. I am giving you a standard problem that tcpwrappers solves and
you need to come up with some sort of replacement for them.  Most real
problems enterprise administrators deal with are people oriented and this
is a tool which deals with those problems in a way that is clean and clear.


All I am trying to do is point them out to you so that you don't end up
having to spend all of 2016 recoding a replacement because it became a deal
breaker for the various enterprise downstreams. If you want

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 08:06:26PM +0100, Florian Weimer wrote:
 I believe DenyHosts is unmaintained as well:

fail2ban is maintained, does basically the same thing, can use iptables and
optionally firewalld, and can watch the systemd journal. Maybe that could go
in the release notes.

I think in general that part of the reason tcp_wrappers has rotted is that
interfaces to packet filtering tools have gotten better and easier over the
past two decades.

I'm basically in favor of this, with a big star put by Stephen Smoogen's
concern about enterprise defense-in-depth policies. But just so no one is
surprised if I say this later, unless there is overwhelming feedback that
it's time for it to go now, I think it's reasonable to declare it deprecated
for F21, with release notes, warnings in hosts.allow and hosts.deny, updates
in the documentation (which current recommends using both in conjunction)
http://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sect-Security_Guide-Server_Security.html#sect-Security_Guide-Server_Security-Securing_Services_With_TCP_Wrappers_and_xinetd
and so on. Then if that goes smoothly and gets positive (or, zero) user
feedback, we can remove it for F22.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Hans de Goede

Hi,

On 03/20/2014 07:45 PM, Lennart Poettering wrote:
 On Thu, 20.03.14 14:31, Martin Langhoff (martin.langh...@gmail.com) wrote:
 
 On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering 
 mzerq...@0pointer.dewrote:

 I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
 Fedora. There has been a request in systemd upstream to disable support


 As Stephen points out, they are used. Does systemd+xinetd match their
 functionality?
 
 No. systemd is not a firewall. It currently supports libwrap checks for
 socket activated services. And I'd really like to get rid of that...
 
 I have no doubt that some people use them, however I am also pretty sure
 that they are massively awful, and not worth the trouble, and that I'd
 prefer not to see this crap in the default install. However, since the
 library is currently hooked into a lot of services (starting with
 systemd itself) I currently cannot do rpm -e.
 
 I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if
 people want to make use of that. I am simply proposing to not link
 agains them anymore for everything that is in the default system.

So as an innocent bystander who happens to be reading along this thread,
I see 2 sides to the story here:

Lennart says:
1) It is horrible code
2) It really really is horrible horrible code
3) And there are other ways to achieve the same goal, so lets kill it

Others say:
1) There may be other ways but non so easily central managed with with
a unified syntax for all services

The argument which the others are making actually sounds a lot like
a lot of the arguments in favor of systemd (wrt standardizing, etc.).

And I'm getting the feeling that Lennart is not as much opposed to the
functionality of tcp-wrappers, as that he *really* hates the code.

So maybe a solution would be to write a libwrap2 instead ?

So offer something with equivalent functionality (and config file
syntax compatibility), with a nice modern clean API and then systemd
and others can be moved over to that 1 by 1, and once we've no more
users left we can kill of the old beast ?

Note I've nothing to do with anything in this discussion, but I
just noticed a certain trend in it and I hope the above may lead
to a more fruitful discussion.

Regards,

Hans
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

2014-03-20 Thread Chris Murphy


On Mar 20, 2014, at 1:39 PM, Adam Williamson awill...@redhat.com wrote:

 Sigh, for the fourth time, I'm not suggesting it. It's not my idea. I'm
 not going to defend it. I'm relaying a design that was outlined to me by
 the anaconda devs. The motivation is that there have been multiple
 requests to make it possible to have a redundant boot chain on native
 UEFI installs, as you can on native BIOS installs.

Sure but the burden is on whatever installs to or modifies the ESP. Anaconda 
needs to create the required ESPs on each selected device, install the 
bootloader to each ESP, and then either:

a. mount and call grub2-mkconfig on each ESP in turn
b. write a basic forwarding grub.cfg on each ESP, and grub2-mkconfig in the 
normal location /boot/grub2.

For kernel updates:

a. means either the kernel package or grubby must be capable of finding and 
mounting each ESP, and updating their grub.cfg's.
b. means doing nothing new. Grubby updates grub.cfg at /boot/grub2, which is 
made redundant by virtue of whatever the underlying scheme is for the boot 
volume.


The b. path is easier for both single device and multiple device installs than 
what we have now; and it essentially eliminate needing to update or sync ESPs, 
and therefore no need to auto or persistently mount it. It kills multiple birds 
with one stone. (Sorry birds.)


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Erinn Looney-Triggs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/20/2014 01:55 PM, Hans de Goede wrote:
 Hi,
 
 On 03/20/2014 07:45 PM, Lennart Poettering wrote:
 On Thu, 20.03.14 14:31, Martin Langhoff
 (martin.langh...@gmail.com) wrote:
 
 On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering
 mzerq...@0pointer.dewrote:
 
 I wonder whether it wouldn't be time to say goodbye to
 tcpwrappers in Fedora. There has been a request in systemd
 upstream to disable support
 
 
 As Stephen points out, they are used. Does systemd+xinetd match
 their functionality?
 
 No. systemd is not a firewall. It currently supports libwrap
 checks for socket activated services. And I'd really like to get
 rid of that...
 
 I have no doubt that some people use them, however I am also
 pretty sure that they are massively awful, and not worth the
 trouble, and that I'd prefer not to see this crap in the default
 install. However, since the library is currently hooked into a
 lot of services (starting with systemd itself) I currently cannot
 do rpm -e.
 
 I mean, I really don't mind that tcpd/tcpwrap stays in the
 archives, if people want to make use of that. I am simply
 proposing to not link agains them anymore for everything that is
 in the default system.
 
 So as an innocent bystander who happens to be reading along this
 thread, I see 2 sides to the story here:
 
 Lennart says: 1) It is horrible code 2) It really really is
 horrible horrible code 3) And there are other ways to achieve the
 same goal, so lets kill it
 
 Others say: 1) There may be other ways but non so easily central
 managed with with a unified syntax for all services
 
 The argument which the others are making actually sounds a lot
 like a lot of the arguments in favor of systemd (wrt standardizing,
 etc.).
 
 And I'm getting the feeling that Lennart is not as much opposed to
 the functionality of tcp-wrappers, as that he *really* hates the
 code.
 
 So maybe a solution would be to write a libwrap2 instead ?
 
 So offer something with equivalent functionality (and config file 
 syntax compatibility), with a nice modern clean API and then
 systemd and others can be moved over to that 1 by 1, and once we've
 no more users left we can kill of the old beast ?
 
 Note I've nothing to do with anything in this discussion, but I 
 just noticed a certain trend in it and I hope the above may lead to
 a more fruitful discussion.
 
 Regards,
 
 Hans
 

Hans,
Now that is just too entirely rational ;).

This sounds like a wonderful solution, but someone has to be willing
to write the thing.

- -Erinn

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJTK0hrAAoJEFg7BmJL2iPOsnwH/0q5Kf7GvOMKaAemk9y/mYmE
nsB0QHt8nVhWTOd+T4O726loBZlE5pEzhdFTseIROYsmrSsKaKl7DR44CuVSOyXp
q0+TDkT17YxpbrM1OqZWFVW3osbvQo2dohgwaCovviOOiKKHprSC/teTRJ3eKjZI
B1Ymw6PnxzAdyNkrisWqgSpTCCTKvqCLDqLXVRLpC8K/3rj5IY7h8CPg2Ny3ORZI
vL6bP4cAfvdS3wmKeSSIPzvRroPORSWTVJ3IOkvX3NBuWweaIh5nxqP1kiLbkx5G
a8akc48Lhq1DKD0L7aAOHzPb4gtBDw6YnkJu6soCBA0eguRUhyMSMMwrcZBqkoI=
=k0nE
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Oron Peled


On Thursday 20 March 2014 19:45:32 Lennart Poettering wrote:
 No. systemd is not a firewall. It currently supports libwrap checks for
 socket activated services. And I'd really like to get rid of that...

Confession: I've never bothered looking in tcpwrappers code/api, so
I'll take your assessment that this code should be thrown away...

However, the functionality *at the service level* has its value,
as a complement to firewall rules which are global by nature.

Let's look at familiar NON-tcpwrappers examples:
 * Every sane network service allows you to bind to specific interfaces
   although you could protect them via firewall rules.

   It's not *only* security, but also flexibility (e.g: running several
   instances on several [physical or virtual] network interfaces).

   Sometimes it's just extra *safety* (e.g: you don't want an internal
   DHCP server to answer hosts on the corporate network by mistake).

 * You mentioned yourself the sshd Match keyword. Again, it's not just
   security per-se, but the softer ability to control a network
   resource *at the service level*.

 * xinetd also support some socket control options (besides optional
   tcpwrappers integration). E.g: per_source or cps directives.

 * Last, a somewhat theoretical example. User-level services.
   (e.g: screen sharing of personal desktop like krfb).
   The non-root user may not have global control on the host and firewall
   but may want to set limits who can bother him/her.

   (it's theoretical simply because current implementations doesn't
give the user any such control ;-)

So is there any chance to have similar functionality?
 * IMO, exact feature/syntax parity with tcpwrappers isn't important at all.

 * However, *some* optional socket control/limits in service.socket file
   would go a long way.

 * If this happens to be implemented in a small library with sane API,
   it may even contribute to the direct replacement of tcpwrappers
   in other network services that need similar features...

Thanks,


-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron

The wonderful thing about standards is that there are so many of
them to choose from.
-- Grace Murray Hopper

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Stephen John Smoogen

On 20 March 2014 13:55, Hans de Goede hdego...@redhat.com wrote:

 Hi,

 On 03/20/2014 07:45 PM, Lennart Poettering wrote:
  On Thu, 20.03.14 14:31, Martin Langhoff (martin.langh...@gmail.com)
 wrote:
 
  On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering 
 mzerq...@0pointer.dewrote:
 
  I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
  Fedora. There has been a request in systemd upstream to disable support
 
 
  As Stephen points out, they are used. Does systemd+xinetd match their
  functionality?
 
  No. systemd is not a firewall. It currently supports libwrap checks for
  socket activated services. And I'd really like to get rid of that...
 
  I have no doubt that some people use them, however I am also pretty sure
  that they are massively awful, and not worth the trouble, and that I'd
  prefer not to see this crap in the default install. However, since the
  library is currently hooked into a lot of services (starting with
  systemd itself) I currently cannot do rpm -e.
 
  I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if
  people want to make use of that. I am simply proposing to not link
  agains them anymore for everything that is in the default system.

 So as an innocent bystander who happens to be reading along this thread,
 I see 2 sides to the story here:

 Lennart says:
 1) It is horrible code
 2) It really really is horrible horrible code
 3) And there are other ways to achieve the same goal, so lets kill it

 Others say:
 1) There may be other ways but non so easily central managed with with
 a unified syntax for all services

 The argument which the others are making actually sounds a lot like
 a lot of the arguments in favor of systemd (wrt standardizing, etc.).

 And I'm getting the feeling that Lennart is not as much opposed to the
 functionality of tcp-wrappers, as that he *really* hates the code.

 So maybe a solution would be to write a libwrap2 instead ?

 So offer something with equivalent functionality (and config file
 syntax compatibility), with a nice modern clean API and then systemd
 and others can be moved over to that 1 by 1, and once we've no more
 users left we can kill of the old beast ?

 Note I've nothing to do with anything in this discussion, but I
 just noticed a certain trend in it and I hope the above may lead
 to a more fruitful discussion.


Yes I agree Hans. I think this is the rational and correct course. I also
realize that it isn't Lennart's job to do so even if I wish he would.


-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 03:50:07PM -0400, Matthew Miller wrote:
 it's time for it to go now, I think it's reasonable to declare it deprecated
 for F21, with release notes, warnings in hosts.allow and hosts.deny, updates

And by declare, I mean decide collectively to declare -- sorry if that
was unclear.




-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Miloslav Trmač

2014-03-20 20:55 GMT+01:00 Hans de Goede hdego...@redhat.com:

 Lennart says:
 1) It is horrible code
 2) It really really is horrible horrible code
 3) And there are other ways to achieve the same goal, so lets kill it

 Others say:
 1) There may be other ways but non so easily central managed with with
 a unified syntax for all services


Yes.  It's notable that almost every widely-used network server that
doesn't use tcp_wrappers has needed to add a very similar set of options;
so we shouldn't expect that tcp_wrappers were removed users would stop
using or asking for that kind of functionality.

Centralizing the language, semantics and implementation is clearly a better
UI and better design.  Not only for the common case of the same option has
a different name in the other daemon, but also for the corner cases like
error behavior where various independent implementations differ in
surprising ways.  Such surprises are great starting points for attackers
looking to bypass policy.

From the users' POV, moving from tcp_wrappers to per-daemon configuration
is a clear step backwards.  If the implementers' POV differs, that's a
reason to change the implementation, not to discard the feature.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Philip Prindeville


On Mar 20, 2014, at 12:31 PM, Martin Langhoff martin.langh...@gmail.com wrote:

 On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerq...@0pointer.de 
 wrote:
 I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
 Fedora. There has been a request in systemd upstream to disable support
 
 As Stephen points out, they are used. Does systemd+xinetd match their 
 functionality?
 
 cheers,
 
 
 m

I have to say that there are certain out-of-the-box services that it’s nice to 
be able to block access at the application-level, which would be hard to do at 
the transport or network layer.

RPC-based services being the most obvious, but also things like FTP or TFTP or 
VNC or X that don’t always have port numbers that are easily expressed…  Then 
there’s filtering on DNS hostname suffixes, etc… NIS+ membership...

I’m fine with seeing systemd being decoupled from them, but I’d like to see 
legacy services continue to work with tcpwrappers (libwrap).

-Philip


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Richard W.M. Jones

On Thu, Mar 20, 2014 at 10:48:53PM +0200, Oron Peled wrote:
 
 On Thursday 20 March 2014 19:45:32 Lennart Poettering wrote:
  No. systemd is not a firewall. It currently supports libwrap checks for
  socket activated services. And I'd really like to get rid of that...
 
 Confession: I've never bothered looking in tcpwrappers code/api, so
 I'll take your assessment that this code should be thrown away...

I did just look at the code, and it doesn't look too bad to me.  I'd
be interested hearing about specific problems with it.

  http://gitweb.dragonflybsd.org/dragonfly.git/tree?f=contrib/tcp_wrappers

On the other hand, I'll note that Arch dropped tcp_wrappers support in 2011.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 20:36, Florian Weimer (f...@deneb.enyo.de) wrote:

  OpenSSH can do this on its own without involving tcpwrap:
 
  https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html
 
  It sounds like a much better choice to stick to that instead of
  involving tcpwrap, and we should push our users to understand that...
 
 The nice thing about tcpwrappers is that it runs extremely early,
 typically before any application code is exposed.  Something in the
 guts of OpenSSH really isn't comparable.  It's not immediately obvious
 how you'd block logins altogether.

Well, the thing though is that the OpenSSH code is not as bad as
tcpwrap. I'd much rather have OpenSSH handle this than tcpwrap...

And if it's not immediately obvious, then we can certainly fix that
with adding more docs, or explaining this in the release notes?

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 13:44, Stephen John Smoogen (smo...@gmail.com) wrote:

  Well, all mails servers as well as sshd have much better ways to do
  such filtering. sshd has Match,  Postfix for example has
  smtpd_client_restrictions=, and so on.
 
 And now I need to have X number applications special syntax to
 whitelist/blacklist a site. I need to change X files to make that change.
 Each of those could be a separate change control process depending on the
 size of the organization. Or I have 1 file that I can make a change to
 which has usually one syntax and one set of reviews.

Well, if you filter in postfix or ssh, then you have a domain-specific,
powerful language there. You can not only match on source addresses, but
also on user names, groups, authentication methods, connection features
SASL schemes, crypto algorithms, ... It's a very good thing being able
to control this in a unified, but domain-specific way. There are also
proper firewalls, for traffic-level filtering. But where's the place for
tcpwrappers in all of this? It's neither really generic, nor
domain-specific, and also crappy code. We really don't need 3 layers
checking the very same thing...

postfix and sshd have mechanisms to filter for on specific domain each,
however covering a multitude of domain-specific high-level, matches and
actions.

A firewall has mechanisms to filter for all domains, however only
covering a smaller number of generic, low-level matches and actions.

tcpwrap otoh is somewhere in the middle, it's neither really generic,
nor really powerful. It's not a convincing, a very redundant option,
since it gets you very little features on top of a firewall, and is not
that universal either.

 Look I am not saying it isn't horrible to look at from a coding side. From
 a systems administrators side it does stuff in a very clean, easily audited
 way. It is also a nice key place where every application is actually using
 the same syntax versus each custom version. Having spent several ITIL
 meetings where you have to explain the syntax of each application to
 non-sysadmins, then prove that the change is correct, then prove that the
 change is easily backed out, and then other parts.. having 1 syntax to do
 that versus doing every applications custom version makes it a lot easier
 to deal with.

If you want that unified language that can actually cover all kinds of
apps and traffic, then use a firewall. It is truly universal (unlike
tcpwrappers), and at least as powerful...

 I am not saying rip it out, but I am saying that you need something that
 replaces that one syntax, one file control, simple syntax method.

Let that be the firewall. It does the same thing, just better.

 I am giving you a standard enterprise problem. You are constantly going on
 about how systemd solves enterprise level problems and enterprises will
 love them. I am giving you a standard problem that tcpwrappers solves and
 you need to come up with some sort of replacement for them.  Most real
 problems enterprise administrators deal with are people oriented and this
 is a tool which deals with those problems in a way that is clean and
 clear.

Yupp, here's my replacement: a proper firewall.

And no, it's not a standard enterprise problem that firewalls need
higher people's sign-off than tcpwrappers in your theoretic firewall..

 All I am trying to do is point them out to you so that you don't end up
 having to spend all of 2016 recoding a replacement because it became a deal
 breaker for the various enterprise downstreams. If you want to make this a
 You dare question me? then fine, I can go do something else and know in
 the future that you aren't really looking for feedback.

You know, we have more powerful replacements both high-level (in
postfix, sshd, ...) and lower-level, we really don't need tcp wrappers.

I posted this here for feedback, and yes I got it, please understand
though at I will at least try to convince you that tcpwrap is a
dead-end. I mean, take it as an indication that I am actually taking
your feedback seriously, that I spend a lot of time arguing against
it. If I wouldn't take it seriously I wouldn't have started this
discussion and would certainly not have replied to this message...

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Reindl Harald



Am 21.03.2014 01:00, schrieb Lennart Poettering:
 On Thu, 20.03.14 13:44, Stephen John Smoogen (smo...@gmail.com) wrote:
 
 Well, all mails servers as well as sshd have much better ways to do
 such filtering. sshd has Match,  Postfix for example has
 smtpd_client_restrictions=, and so on.

 And now I need to have X number applications special syntax to
 whitelist/blacklist a site. I need to change X files to make that change.
 Each of those could be a separate change control process depending on the
 size of the organization. Or I have 1 file that I can make a change to
 which has usually one syntax and one set of reviews.
 
 Well, if you filter in postfix or ssh, then you have a domain-specific,
 powerful language there. You can not only match on source addresses, but
 also on user names, groups, authentication methods, connection features
 SASL schemes, crypto algorithms

what has this to do with I have 1 file that I can make a change to
which has usually one syntax and one set of reviews?




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Martin Langhoff

On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering mzerq...@0pointer.dewrote:

 A firewall has mechanisms to filter for all domains, however only
 covering a smaller number of generic, low-level matches and actions.


From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if teaching
firewalld to support some of that functionality would help here.

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Martin Langhoff

On Thu, Mar 20, 2014 at 8:04 PM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering 
 mzerq...@0pointer.dewrote:

 A firewall has mechanisms to filter for all domains, however only
 covering a smaller number of generic, low-level matches and actions.


 From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if
 teaching firewalld to support some of that functionality would help here.


To clarify: what I mean is that firewalld could parse the legacy files,
interpreting the rules that are translatable, failing safely for those that
are are not.

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff



-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 20:55, Hans de Goede (hdego...@redhat.com) wrote:

  I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if
  people want to make use of that. I am simply proposing to not link
  agains them anymore for everything that is in the default system.
 
 So as an innocent bystander who happens to be reading along this thread,
 I see 2 sides to the story here:
 
 Lennart says:
 1) It is horrible code
 2) It really really is horrible horrible code
 3) And there are other ways to achieve the same goal, so lets kill it

I am not just saying other ways, but *better* ways.

I am also saying that keeping this around makes the OS unnecessarily more 
complex.

 Others say:
 1) There may be other ways but non so easily central managed with with
 a unified syntax for all services
 
 The argument which the others are making actually sounds a lot like
 a lot of the arguments in favor of systemd (wrt standardizing, etc.).

Well the difference here is pretty much that there was no
pre-existing standardization effort for the areas that systemd covered
really. 

However, there's a technically much better, established, better
understood alternative to tcpwrappers, and that's a firewall.

 And I'm getting the feeling that Lennart is not as much opposed to the
 functionality of tcp-wrappers, as that he *really* hates the code.

I am actually against this as seperate functionality too. Go high-level
with service-specific filtering. Or go low-level with a firewall. Don't
waste your time with tcpwrap...

 So maybe a solution would be to write a libwrap2 instead ?

Oh, please no. We already have firewalls for this.

If you want to write new code: I think it would be a lot nicer to simply
write a converter for hosts.allow and hosts.deny into iptables rules,
plus some warnings if DNS and IDENT matches are used.

 So offer something with equivalent functionality (and config file
 syntax compatibility), with a nice modern clean API and then systemd
 and others can be moved over to that 1 by 1, and once we've no more
 users left we can kill of the old beast ?

Nope. In systemd we already support one subsystem for filtering just
fine, it's called a firewall. I am looking for a way to simplify things,
and remove unnecessary redundancies. And just rewriting something that
is redundant and a bad idea in the first place, certainly doesn't help
there...

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 Thread Reindl Harald



Am 21.03.2014 01:17, schrieb Lennart Poettering:
 On Thu, 20.03.14 20:55, Hans de Goede (hdego...@redhat.com) wrote:
 So offer something with equivalent functionality (and config file
 syntax compatibility), with a nice modern clean API and then systemd
 and others can be moved over to that 1 by 1, and once we've no more
 users left we can kill of the old beast ?
 
 Nope. In systemd we already support one subsystem for filtering just
 fine, it's called a firewall. I am looking for a way to simplify things,
 and remove unnecessary redundancies. And just rewriting something that
 is redundant and a bad idea in the first place, certainly doesn't help
 there...

http://en.wikipedia.org/wiki/Defence_in_depth#Non-military_examples



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?