Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords

[Dan Lüdtke]

What the... This discussion has become a bit out of hand!

My goal was to have consistency at LuCI and CLI. I see how enforcing passwords 
of a particular kind, as well as enforcing passwords at all, is not an 
engineering decision. I have no problem with this patch being rejected.

So, since we decided to not enforce anything regarding passwords for the root 
user on CLI,  I think we should also not enforce anything regarding passwords 
for the root user on LuCI. Still, I am concerned about consistency foremost.

This PR needs to be rejected to stay consistent, then!
--> https://github.com/openwrt/luci/pull/878

Cheers,

Dan

PS: Ah, I see that patchwork rejected the patch already. All good!


> On 17 Feb 2017, at 13:51, David Lang  wrote:
> 
> On Fri, 17 Feb 2017, Alberto Bursi wrote:
> 
>> On 02/17/2017 12:52 PM, David Lang wrote:
>>> On Fri, 17 Feb 2017, Alberto Bursi wrote:
>>> 
>>> And having no password is a much bigger change than having a short
>>> password when you are testing things. It makes a lot of sense to be
>>> excercising the password routine when doing tests, and very little
>>> difference if you are excercising it with a short password or a long one.
>>> 
>> 
>> What? if I'm testing things that are completely unrelated to login
>> (system configurations for tutorials or stuff for device support) then
>> how I log in is irrelevant.
> 
> if you are testing specific features, than any other features are irrelevant, 
> but if you are doing more general testing, then one of the things that needs 
> to be in the tests is the authentication.
> 
> and if you are setting up test scripts, it's best to make them scripts that 
> users can test with as well, and they are almost always going to have 
> authentication enabled.
> 
>>> Why are you saying that short passwords are bad? Is it just because you
>>> have been told that they are?
>>> 
>>> Remember, a short password is only a problem if attackers have the
>>> ability to make brute force attacks on the system. If attackers can't
>>> get at the interface, or if there are other strategies in place to
>>> defeat brute force attacks, a short password can be acceptable.
>>> 
>> 
>> True. Are there such systems in place for ssh access?
> 
> They are available.
> 
> To start with, SSH access is not enabled on the WAN side.
> 
> If password brute forcing from the inside is considered a threat, then 
> turning on rate limiting/temporary lockouts/alerts/etc is a far better thing 
> to do than to try to force 'better' passwords.
> 
> people who don't want good passwords are going to find a way to not have good 
> passwords.
> 
> password1! is not a much better password to use than password, even though 
> the password strength tests will claim that it is. If you force people to 
> have 'longer' or 'more complex' passwords, they are far more likely to add 
> some easy to guess nonsense on the end of their previous 'bad' password than 
> to come up with a 'good' password.
> 
> David Lang
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords

[Dan Lüdtke]

Hi David,

thanks for the fast response!

> On 17 Feb 2017, at 11:54, David Lang  wrote:
> But deciding that you know better than the admin of the system is not.

Not that I am a fan of telling admins what to do, but do you see any chance 
that we  can get an consistent and enforceable approach to *minimum* 
requirements, e.g. minimum password length? Maybe by using a configuration 
variable? Havon only the GUI enforce minimum password length and not the CLI is 
rather inconsistent (some may say useless or even confusing).

> 
> you don't have any idea what the security environment is for the system, or 
> why the admin is selecting that password.
> 
> It's not just a busybox thing to allow the root user to select a password 
> that is shorter than 'recommended', that's normal behavior on *nix systems 
> and has been for decades, even as the 'recommendations' have changed.

I rather see this as a "LEDE" system not a standard *nix system, even though it 
is based on Linux and runs a Linux kernel. The question is, is this a more a 
"product" or just another Linux system?

"has been for decades" is not a good argument. The others are. But that one is 
just not.


Cheers,

Dan
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] s/dnsmasq/unbound+odhcpd/

[Dan Lüdtke]

Hi everyone,

i built LEDE without dnsmasq but with odhcp instead. Mainly out of curiosity 
and to test a recent PR by Eric Luehrsen regarding unbound+odhcp.

Just a couple of questions to help me understand why things are the way they 
are:


A) In ifaces.lua, it says "Display DNS settings if dnsmasq is available" but 
instead of DNS, DHCP4+6 and RA come next. Wrong comment or did I miss something?

https://github.com/openwrt/luci/blob/44bf3f0c1640040561306caff39f34ac916b4357/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/ifaces.lua#L385

B) test for 'if has_dnsmasq and net:proto() == "static" then' should yield 
false on my built, since it has not dnsmasq, but i still see the section in 
luci. However, I pressed the button saying "add dhcp server" or something like 
this. But that should not influence has_dnsmasq, right?
https://github.com/openwrt/luci/blob/44bf3f0c1640040561306caff39f34ac916b4357/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/ifaces.lua#L389

local has_dnsmasq  = fs.access("/etc/config/dhcp") seems to be the line in 
charge of setting the variable. I propose it is renamed to has_dhcp
https://github.com/openwrt/luci/blob/44bf3f0c1640040561306caff39f34ac916b4357/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/ifaces.lua#L13

C) How easy it is to determine if dnsmasq and/or odhcp are installed? I like to 
make the GUI capable of configuring odhcpd, too. Some functions do work 
already, but that is due to the fact that ODHCPD reads some of dnsmasq/luci 
variables fine. Some not (ignored) and some are missing. --> 
https://github.com/sbyx/odhcpd

I would like to add conditionals to each input field that is dhcp-server 
specific and only have the non-specific appear unconditionally. Good idea? Bad 
idea?
I want to avoid creating a luci-app-odhcp, that does not look like good 
integration to me. Other opinions?


Background for all of this is, that I have some nice hardware (lots of RAM for 
a router) and would like to replace dnsmasq with unbound+odhcpd to get 
recursion, validation, dns64 and a minimal dhcp server. It would be nice if 
user experience via LUCI would be on par in this setup with what we know and 
love from dnsmasq. I'd like to help in making this possible.


Thanks for your help!

Cheers,

Dan



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [Jool-list] It seems to me like the build system ignores EXTRA_FLAGS?

[Dan Lüdtke]

Hi guys,

you are totally right. I had the -largp in the wrong place the whole time.
I found that the easiest way to work around the issue is to patch the 
Makefile.am files when they are getting pulled in by the build system. See 
patch below.

In the meantime, Jo came up with a fixed Makefile that does not need patches of 
upstream Makefile.am files. I tested it and it builds fine. Thank you very 
much! So I threw away the patches and use the proper Makefile now.

Building works, tests on the target platform have been successful as well. I 
opened a pull request where we can discuss any other issues that need to get 
sorted out before merging.

Thanks for you help and the super-fast responses!

Dan

Pull Request is here: https://github.com/openwrt/packages/pull/3604

> On Thu, Dec 1, 2016 at 9:34 AM, Alberto Leiva  wrote:
>> 
>> Not sure if "x86_64-openwrt-linux-musl-gcc" implies that you're using gcc,
>> but at least in stock gcc, order matters. If you're going to force -largp,
>> do so at the end, along with the other libraries.


> On 1 Dec 2016, at 10:20, John Szakmeister  wrote:
> 
> I can't help you with the actual issues, but you don't have -largp in
> the correct location.  It need probably needs to come before the last
> few libraries, but after the jool-related ones (at the very least the
> ones that depend on it).  Linkers link in the order given, so at the
> point you've placed it, nothing depends on argp and therefore nothing
> is used from it.


--- a/usr/stateful/Makefile.am  2016-10-07 20:17:00.0 +0200
+++ b/usr/stateful/Makefile.am  2016-12-01 13:40:23.034974511 +0100
@@ -25,7 +25,7 @@
../common/target/pool6.c \
../common/target/session.c
 
-jool_LDADD = ${LIBNLGENL3_LIBS}
+jool_LDADD = -largp ${LIBNLGENL3_LIBS}
 jool_CFLAGS = -Wall -O2
 jool_CFLAGS += -I${srcdir}/../../include
 jool_CFLAGS += ${LIBNLGENL3_CFLAGS} ${JOOL_FLAGS}
--- a/usr/stateless/Makefile.am 2016-10-07 20:17:00.0 +0200
+++ b/usr/stateless/Makefile.am 2016-12-01 13:40:01.034717994 +0100
@@ -25,7 +25,7 @@
../common/target/pool6.c \
../common/target/session.c
 
-jool_siit_LDADD = ${LIBNLGENL3_LIBS}
+jool_siit_LDADD = -largp ${LIBNLGENL3_LIBS}
 jool_siit_CFLAGS = -Wall -O2
 jool_siit_CFLAGS += -I${srcdir}/../../include
 jool_siit_CFLAGS += ${LIBNLGENL3_CFLAGS} ${JOOL_FLAGS}
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [Jool-list] It seems to me like the build system ignores EXTRA_FLAGS?

[Dan Lüdtke]

I created a pull request on github for this one. 

> On 30 Nov 2016, at 23:31, Alberto Leiva  wrote:
> 
> Yes, from your build log, it does look like it ignores EXTRA_FLAGS. Autoconf 
> is the one normally supposed to take care of the -ls. Don't know if 
> you've tried this: Open usr/configure.ac and add
> 
> AC_SEARCH_LIBS([argp_parse], [argp])
> [...]
> You might want to send a pull request if it works.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] It seems to me like the build system ignores EXTRA_FLAGS?

[Dan Lüdtke]

Hi Jo,


> try using TARGET_LDFLAGS += -largp

Makefile for reference below and here: 
https://paste.fedoraproject.org/494537/05830811/

Result:
> x86_64-openwrt-linux-musl-gcc -Wall -O2 -I./../../include 
> -I/home/danrl/lede/nat64/source/staging_dir/target-x86_64_musl-1.1.15/usr/include/libnl3
>  -o jool ../../common/netlink/jool-config.o 
> ../../common/stateful/jool-xlat.o ../common/jool-cJSON.o ../common/jool-dns.o 
> ../common/jool-file.o ../common/jool-jool.o ../common/jool-netlink2.o 
> ../common/jool-str_utils.o ../common/argp/jool-options.o 
> ../common/nl/jool-buffer.o ../common/target/jool-bib.o 
> ../common/target/jool-eam.o ../common/target/jool-global.o 
> ../common/target/jool-instance.o ../common/target/jool-joold.o 
> ../common/target/jool-json.o ../common/target/jool-log_time.o 
> ../common/target/jool-pool.o ../common/target/jool-pool4.o 
> ../common/target/jool-pool6.o ../common/target/jool-session.o 
> -L/home/danrl/lede/nat64/source/staging_dir/target-x86_64_musl-1.1.15/usr/lib 
> -lnl-genl-3 -lnl-3 -lpthread -lm 
> ../common/jool-jool.o: In function `main':
> jool.c:(.text.startup+0x89): undefined reference to `argp_parse'
> collect2: error: ld returned 1 exit status
> Makefile:504: recipe for target 'jool' failed
> make[6]: *** [jool] Error 1

The flags don't show up in the final command as far as I can tell. But even if 
it would, the error stays the same. (See other mail). I am puzzled why this 
happens.


I don't think it is a good idea, but would it be possible to make this Package 
depend on using glibc for the toolchain? I tried to squeeze it into DEPENDS:= 
but that wasn't working well.

The package works for me, as I use glibc in the toolchain. I like to upstream 
it into LEDE/OpenWRT so that others can use it, too, but it breaks the build 
currently. Frustrating. Why is argp such a rocket science? Can't believe 
something as basic as this isn't in musl.


Dan


Makefile:
#
# Copyright (C) 2016 Dan Luedtke 
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.

include $(TOPDIR)/rules.mk

PKG_NAME:=jool
PKG_VERSION:=3.5.1
PKG_RELEASE:=1

PKG_LICENSE:=GPL-3.0
PKG_LICENSE_FILES:=COPYING

PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=https://github.com/danrl/Jool.git
PKG_SOURCE_VERSION:=c3463caf91781c1ebb40249f236f6ae028c88f74
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_SOURCE_VERSION)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_SOURCE_VERSION).tar.gz
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_SOURCE_SUBDIR)
PKG_BUILD_PARALLEL:=1
PKG_BUILD_DEPENDS:=+argp-standalone +automake
PKG_AUTOMAKE_PATHS:=usr
#PKG_FIXUP:=autoreconf
MAKE_PATH:=usr

TARGET_LDFLAGS += -largp

# does not work
#EXTRA_CFLAGS:=-largp-standalone
#EXTRA_LDFLAGS:=-largp-standalone

# does not work either
#EXTRA_CFLAGS:=-largp
#EXTRA_LDFLAGS:=-largp

include $(INCLUDE_DIR)/kernel.mk
include $(INCLUDE_DIR)/package.mk

define Package/jool/Default
SECTION:=net
CATEGORY:=Network
URL:=https://www.jool.mx
MAINTAINER:=Dan Luedtke 
endef

define Package/jool/Default/description
Jool is an Open Source SIIT and NAT64 for Linux.
endef

define Package/jool
$(call Package/jool/Default)
TITLE:=Jool meta-package
DEPENDS:=+kmod-jool +jool-tools
endef

define Package/jool/description
$(call Package/jool/Default/description)
endef

include $(INCLUDE_DIR)/kernel-defaults.mk
include $(INCLUDE_DIR)/package-defaults.mk

define KernelPackage/jool
SECTION:=kernel
CATEGORY:=Kernel modules
SUBMENU:=Network Support
TITLE:=Jool kernel module
DEPENDS:= \
@IPV6 \
+kmod-crypto-md5 \
+kmod-nf-conntrack \
+kmod-nf-conntrack6
FILES:= \
$(PKG_BUILD_DIR)/mod/stateful/jool.$(LINUX_KMOD_SUFFIX) \
$(PKG_BUILD_DIR)/mod/stateless/jool_siit.$(LINUX_KMOD_SUFFIX)
endef

define KernelPackage/jool/description
$(call Package/jool/Default/description)

This package provides the kernel module for Jool.
endef

define Package/jool-tools
$(call Package/jool/Default)
TITLE:=Jool userspace control programs
DEPENDS:=+libnl +ethtool
endef

define Package/jool-tools/description
$(call Package/jool/Default/description)

This package provides the userspace control programs for Jool.
endef

define Package/jool-tools/install
$(INSTALL_DIR) $(1)/usr/sbin/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/stateful/jool   $(1)/usr/sbin/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/usr/stateless/jool_siit $(1)/usr/sbin/
endef

define Build/Configure
( cd $(PKG_BUILD_DIR)/usr; ./autogen.sh )
( cd $(PKG_BUILD_DIR)/usr; ./configure )
endef

define Build/Compile
$(MAKE) -C "$(LINUX_DIR)" \
KERNEL_DIR="$(LINUX_DIR)" \
ARCH="$(LINUX_KARCH)" \
CROSS_COMPILE="$(TARGET_CROSS)" \
 

Re: [LEDE-DEV] [Jool-list] It seems to me like the build system ignores EXTRA_FLAGS?

[Dan Lüdtke]

> AC_SEARCH_LIBS([argp_parse], [argp])


Result: 
> checking for pow... no
> checking for library containing pow... -lm
> checking for library containing pthread_create... -lpthread
> checking for library containing argp_parse... none required <<<---
> checking pkg-config is at least version 0.9.0... yes
> checking for LIBNLGENL3... yes
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating stateless/Makefile
> config.status: creating stateful/Makefile
> config.status: creating joold/Makefile
> config.status: executing depfiles commands

Sigh. It checks for the lib but doesn't think it needs it. Shouldn't this be 
running all under the same toolchain?

I think it may be the LEDE build system that is screwing this one up. Or my 
Makefile is totally nuts (possible, not very experienced in LEDE build system).

It get's worse. If I force -largp, the error stays the same:
> x86_64-openwrt-linux-musl-gcc -Wall -O2 -largp -I./../../include 
> -I/home/danrl/lede/nat64/source/staging_dir/target-x86_64_musl-1.1.15/usr/include/libnl3
>  -o jool ../../common/netlink/jool-config.o 
> ../../common/stateful/jool-xlat.o ../common/jool-cJSON.o ../common/jool-dns.o 
> ../common/jool-file.o ../common/jool-jool.o ../common/jool-netlink2.o 
> ../common/jool-str_utils.o ../common/argp/jool-options.o 
> ../common/nl/jool-buffer.o ../common/target/jool-bib.o 
> ../common/target/jool-eam.o ../common/target/jool-global.o 
> ../common/target/jool-instance.o ../common/target/jool-joold.o 
> ../common/target/jool-json.o ../common/target/jool-log_time.o 
> ../common/target/jool-pool.o ../common/target/jool-pool4.o 
> ../common/target/jool-pool6.o ../common/target/jool-session.o 
> -L/home/danrl/lede/nat64/source/staging_dir/target-x86_64_musl-1.1.15/usr/lib 
> -lnl-genl-3 -lnl-3 -lpthread -lm 
> ../common/jool-jool.o: In function `main':
> jool.c:(.text.startup+0x89): undefined reference to `argp_parse'
> collect2: error: ld returned 1 exit status
> Makefile:504: recipe for target 'jool' failed
> make[6]: *** [jool] Error 1


However, if I force -largp-standalone (nonexistent) the linker exits 
complaining about how it could not find the lib. This means, in the previous 
command (with forced -largp) the linker found the lib but did not think it 
helps linking argp_parse. Why is that?


Maybe someone from LEDE can help explain this?



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] netifd: proto_add_host_dependency()

[Dan Lüdtke]

Hi everyone,

I have a weird situation where proto_add_host_dependency() does not like IPv6 
addresses. The WAN/WAN6 interface don't have global unicast addresses assigned, 
but my protocol script calls

 proto_add_host_dependency "${config}" "${ip}"

with $ip containing a global unicast address. Interface setup fails. If I use 
IPv4 instead, interface setup succeeds.

I a bit puzzled, because I think I have seen this working before.
Testing on latest (OpenWRT) snapshot. Has netifd diverged in LEDE already?

Source: 
https://github.com/openwrt/packages/blob/d1c890896c0cae4516a222a0adcf01d91f8d0503/net/wireguard/files/wireguard.sh#L87

Any ideas?

Dan
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev