Re: [LEDE-DEV] [PATCH RFC 2/2] x86: lift generic x86-32 target

[Stijn Tintel]

On 17-05-16 23:37, Felix Fietkau wrote:
> On 2016-05-17 23:12, Daniel Golle wrote:
>> * build for pentium4 instead of i486
>> * enable PAE
>> * enable EFI support
>> * enable KVM guest and host support
Is anyone running KVM on a 32bit host? I would leave out KVM host
support here.
> I like this change, but I think I'll wait a bit before applying it to
> see if anybody else has some comments about it.
>
I too think x86 and subtargets need some love, but let's not rush
things. Maybe now is a good time to discus other things related to x86
as well.

E.g., a while ago I created a profile for x86/64 for the PCEngines APU2,
but never submitted it, so I put it at [1] now. Last year, on
OpenWrt-Devel, Felix suggested [2] instead. I would like to hear others'
opinions about this too.

And if any else has other ideas... Looking forward to hear them.

Stijn

[1]
https://git.lede-project.org/?p=lede/stintel/staging.git;a=shortlog;h=refs/heads/apu2
[2]
https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037035.html



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

[LEDE-DEV] rocket cwmp - open tr-069 client for embedded platforms

[Luka Perkov]

Hi all!

prpl Foundation has made the invitation to propose OpenWrt enhancement
ideas which may end up funded by the same organization [1]. With this
email I'm offering to prpl Foundation to fund Rocket CWMP project -
which is the client implementation of CWMP / TR-069 protocol. Since this
is a good opportunity to further extend OpenWrt functionality I'm adding
several other mailing lists in CC and hope to initiate discussions
regarding this proposal and project.

CWMP (TR-069) [2] has a very important role both for ISP and for the
entire ecosystem with manufacturers included. The standard form of CWMP
was primarily developed for a number of Internet access devices, such as
modems, set-top boxes, VolP phones and routers. TR-069 standardizes the
wide area network (WAN) management of CWMP devices and gives Internet
Service Providers a framework and a common language to remotely
provision and manage these devices regardless of device type or
manufacturer. There are around twenty TR-* documents which mostly define
new parameters or extend the RPC (Remote Procedure Call) methods.

CWMP (CPE WAN Management Protocol), sometimes called TR-069 (Technical
Report 069), is a technical specification of a Broadband Forum designed
for remote governing of CPE (Customer Premises Equipment). Seeing that
CWMP is a standardized, text based protocol which offers a communication
between CPE and Auto Configuration Servers (ACS), it can be used between
different equipment manufacturers. 

Couple of years back I've authored the first Open Source TR-069 client
specifically targeting OpenWrt - it was named freecwmp [3]. Since then
I've learned a lot of lessons and in the company, Sartura, the team has
started developing new implementation which solves the limitations of
the old implementation.

If funded, we are going to use the budget to further improve existing
codebase and of course to clean it up and prepare for Open Source
release. In order to make this a success, we will work on the
documentation, testing infrastructure and make it easy for vendors and
hackers to use this project when needed.

I'll be making Rocket CWMP presentation on the prplwrt meeting on May 19
(tomorrow). [4] These meetings are usually recorded and published on
YouTube. I hope that will happen with this meeting as well in case
somebody is interested but is not able to join.

More information about the proposal can be found on the prpl Wiki [5]
and in the proposal documentation [6][7]. Comments are welcome!

Sincerely,
Luka Perkov

[1] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding
[2] https://www.broadband-forum.org/cwmp.php
[3] https://lists.openwrt.org/pipermail/openwrt-devel/2012-June/015655.html
[4] http://lists.prplfoundation.org/pipermail/openwrt/2016-May/000544.html
[5] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding/Rocket_CWMP
[6] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-public.pdf
[7] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-slides-public.pdf

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 11:10, David Lang wrote:

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance
impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was
talked about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not
the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll
point out that if home users are familar with Linux, the odds are good
that it's a flavor of Ubuntu that uses AA rather than Fedora that uses
SELinux. (not worth much because the home user probably hasn't touched
AA or SELinux)


That should not be an argument to do one or the other.
You should ask yourself how far you would want to go in securing a router. 
Personally, I would absolutely love a router with a tight SELinux policy 
since it protects me well from unsavory access from the outside.




do all the compressed filesystems support the tagging needed by SELinux?
what about external drives with FAT* or NTFS?


FAT and NTFS do not support it AFAIK, but how is that a problem?
You'd run SELinux on your internal filesystem.


it's not uncommon for people to attach an external drive for more space, and 
then have stuff run off of that drive.


If SELinux can't find the appropriate labels, does it deny or allow by default.

One of the things that annoys me about SELinux is the fact that a daemon can 
behave differently depending on if it's started by init, or started by the root 
user. I've fielded a lot of problem reports because something worked fine when 
they tested it as root and then failed when init started the process (also as 
uid 0). I've also seen cases where the testing as root created a file/directory 
with a label that isn't allowed when the process is started by init, so they 
have to detect the problem and remove the file to let it be created in the 
correct context.


For the compressed filesystems: I don't know, they will probably support it 
if they're good citizen Linux filesystems.


not all linux filesystems support xattrs.





How do you handle the possible need to re-label your files on a
read-only filesystem?



Don't know, but take a look at Android, it has SELinux enabled in enforcing 
mode (the strongest mode).


android devices tend to have a lot more storage/ram than many routers. They also 
aren't running on read-only filesystems.



what is the difference in kernel size (and tool size) between AA and
SELinux?





Don't know.


For clarity (and for weaseling out): I read a snip of the discussion and 
wanted to offer another alternative, so that the discussion could consider 
it.


And I think it's a good thing to bring up and discuss. I happen to dislike 
SELinux and would not have brought up AppArmor until after things were moved to 
not run as root in the first place. But I think it's a good discussion to have.


I am not trying to shout you down, just raising concerns.

David Lang

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

[LEDE-DEV] MPTCP

[Christian Huldt]

I just built LEDE with MPTCP, but in order to get better integration I'm
reading
https://wiki.openwrt.org/doc/devel/patches#adding_or_editing_kernel_patches

MPTCP is however associated with a bunch of lines in the kernel config,
is there a way to add some defaults there som that make kernel_config is
not necessary?

And is there a way to make the patch only be applied if it is chosen in
make menuconfig?



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Please enable digest mode for lede-dev

[Hannu Nyman]

On 18.5.2016 14:02, Jo-Philipp Wich wrote:

Hi Hannu,


Please allow users to select to receive lede-dev messages in digests.

Done, please let me know whether it is working.

~ Jo



Thanks, it works great. I enabled digest mode and the first digest message 
just arrived :-(


And the MIME digest mode enables picking a single message from the digest 
message and answering to that, decreasing the risk that Arjen mentioned. (At 
least Thunderbird supports these list message digests nicely.)




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

Re: [LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements

[Daniel Curran-Dickinson]

On 16-05-18 07:31 AM, Conor O'Gorman wrote:
> On 18/05/16 12:21, Jo-Philipp Wich wrote:
>> On 05/18/2016 12:12 PM,l...@daniel.thecshore.com  wrote:
>>> >Hi John,
>>> >
>>> >I haven't tested these changes yet,
> Testing would be good before next submission.

The whole point of the [RFC] is that it's a request for comments, prior
to the full submission process.

Regards,

Daniel

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

Re: [LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements

[Conor O'Gorman]

On 18/05/16 12:21, Jo-Philipp Wich wrote:

On 05/18/2016 12:12 PM,l...@daniel.thecshore.com  wrote:

>Hi John,
>
>I haven't tested these changes yet,

Testing would be good before next submission.

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

[LEDE-DEV] [PATCH 2/4] v2: block.c: Add support for checking vfat filesystems

[lede]

From: Daniel Dickinson 

v2: Fix mixup of dosfsck checking ext* and e2fsck checking vfat.

vfat is a common filesystem which users may want to mount on an
OpenWrt/LEDE device, so support peforming filesystem checks
before mount for vfat.

Signed-off-by: Daniel Dickinson 
---
 block.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/block.c b/block.c
index 71ffd0b..5a584cb 100644
--- a/block.c
+++ b/block.c
@@ -628,24 +628,30 @@ static void check_filesystem(struct blkid_struct_probe 
*pr)
pid_t pid;
struct stat statbuf;
const char *e2fsck = "/usr/sbin/e2fsck";
+   const char *dosfsck = "/sbin/dosfsck";
+   const char *ckfs;
 
/* UBIFS does not need stuff like fsck */
if (!strncmp(pr->id->name, "ubifs", 5))
return;
 
-   if (strncmp(pr->id->name, "ext", 3)) {
+   if (!strncmp(pr->id->name, "vfat", 4)) {
+   ckfs = dosfsck;
+   } else if (!strncmp(pr->id->name, "ext", 3)) {
+   ckfs = e2fsck;
+   } else {
ULOG_ERR("check_filesystem: %s is not supported\n", 
pr->id->name);
return;
}
 
-   if (stat(e2fsck, ) < 0) {
+   if (stat(ckfs, ) < 0) {
ULOG_ERR("check_filesystem: %s not found\n", e2fsck);
return;
}
 
pid = fork();
if (!pid) {
-   execl(e2fsck, e2fsck, "-p", pr->dev, NULL);
+   execl(ckfs, ckfs, "-p", pr->dev, NULL);
exit(-1);
} else if (pid > 0) {
int status;
-- 
1.9.1


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

Re: [LEDE-DEV] [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems

[Jo-Philipp Wich]

Hi,

>>> +if (!strncmp(pr->id->name, "vfat", 4)) {

"If fs name starts with vfat ..."

>>> +ckfs = e2fsck;

"... then use the ext4 checker".

>>> +} else if (!strncmp(pr->id->name, "ext", 3)) {

"... else if fs name starts with ext ..."

>>> +ckfs = dosfsck;

"... then use the dosfs checker".

>> Is this the wrong way round?
> 
> Do you mean you mean you think ext should be tested first?

That certainly looks swapped to me as well.

~ Jo

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

[LEDE-DEV] [RFC] uhttpd: [PATCH 1/2] modules: Add proxy module

[lede]

From: Daniel Dickinson 

A first attempt at simple HTTP proxy support (to allow
URL beginning with /prefix to really be access to some
other server; this is potenitally useful with some
web applications, or if you want to have a single
entry point to multiple servers (and aren't serving
huge traffic).

Signed-off-by: Daniel Dickinson 
---

 NOTE: This is basically untested and is provided to get comments
 before proceeding with something which may be of no interest.

 CMakeLists.txt |  11 +-
 client.c   |  90 +++--
 listen.c   |   6 +-
 main.c |  41 +-
 proc.c |  38 ++
 proxy.c| 406 +
 uhttpd.h   |  53 
 utils.c|  52 ++--
 8 files changed, 667 insertions(+), 30 deletions(-)
 create mode 100644 proxy.c

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8514351..3bf39db 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -10,6 +10,7 @@ ADD_DEFINITIONS(-D_FILE_OFFSET_BITS=64 -Os -Wall -Werror 
-Wmissing-declarations
 OPTION(TLS_SUPPORT "TLS support" ON)
 OPTION(LUA_SUPPORT "Lua support" ON)
 OPTION(UBUS_SUPPORT "ubus support" ON)
+OPTION(PROXY_SUPPORT "proxy support" ON)
 
 IF(APPLE)
   INCLUDE_DIRECTORIES(/opt/local/include)
@@ -32,9 +33,7 @@ IF(HAVE_SHADOW)
 ADD_DEFINITIONS(-DHAVE_SHADOW)
 ENDIF()
 
-ADD_EXECUTABLE(uhttpd ${SOURCES})
 FIND_LIBRARY(libjson NAMES json-c json)
-TARGET_LINK_LIBRARIES(uhttpd ubox dl json_script blobmsg_json ${libjson} 
${LIBS})
 
 SET(PLUGINS "")
 IF(LUA_SUPPORT)
@@ -73,6 +72,14 @@ IF(UBUS_SUPPORT)
TARGET_LINK_LIBRARIES(uhttpd_ubus ubus ubox blobmsg_json ${libjson})
 ENDIF()
 
+IF(PROXY_SUPPORT)
+   SET(SOURCES ${SOURCES} proxy.c)
+   ADD_DEFINITIONS(-DHAVE_PROXY)
+ENDIF()
+
+ADD_EXECUTABLE(uhttpd ${SOURCES})
+TARGET_LINK_LIBRARIES(uhttpd ubox dl json_script blobmsg_json ${libjson} 
${LIBS})
+
 IF(PLUGINS)
SET_TARGET_PROPERTIES(${PLUGINS} PROPERTIES
PREFIX ""
diff --git a/client.c b/client.c
index 73e0e49..4643a56 100644
--- a/client.c
+++ b/client.c
@@ -24,9 +24,11 @@
 #include "tls.h"
 
 static LIST_HEAD(clients);
-static bool client_done = false;
+bool client_done = false;
 
 int n_clients = 0;
+int n_connections = 0;
+
 struct config conf = {};
 
 const char * const http_versions[] = {
@@ -40,6 +42,9 @@ const char * const http_methods[] = {
[UH_HTTP_MSG_POST] = "POST",
[UH_HTTP_MSG_HEAD] = "HEAD",
[UH_HTTP_MSG_OPTIONS] = "OPTIONS",
+   [UH_HTTP_MSG_DELETE] = "DELETE",
+   [UH_HTTP_MSG_PUT] = "PUT",
+   [UH_HTTP_MSG_CONNECT] = "CONNECT",
 };
 
 void uh_http_header(struct client *cl, int code, const char *summary)
@@ -73,7 +78,7 @@ static void uh_connection_close(struct client *cl)
ustream_state_change(cl->us);
 }
 
-static void uh_dispatch_done(struct client *cl)
+void uh_dispatch_done(struct client *cl)
 {
if (cl->dispatch.free)
cl->dispatch.free(cl);
@@ -104,7 +109,7 @@ static void uh_keepalive_poll_cb(struct uloop_timeout 
*timeout)
cl->us->notify_read(cl->us, 0);
 }
 
-static void uh_poll_connection(struct client *cl)
+void uh_poll_connection(struct client *cl)
 {
cl->timeout.cb = uh_keepalive_poll_cb;
uloop_timeout_set(>timeout, 1);
@@ -160,6 +165,49 @@ static int find_idx(const char * const *list, int max, 
const char *str)
return -1;
 }
 
+#ifdef HAVE_PROXY
+static int client_parse_response(struct client *cl, char *data)
+{
+   struct client *proxycl = cl->proxycl;
+
+   if (!proxycl)
+   return CLIENT_STATE_DONE;
+
+   struct http_request *req = >request;
+   char *code, *msg, *version;
+   int h_version;
+
+   version = strtok(data, " ");
+   code = strtok(NULL, " ");
+   msg = strtok(NULL, " ");
+   if (!code || !msg || !version)
+   goto error;
+
+   memset(>request, 0, sizeof(cl->request));
+   h_version = find_idx(http_versions, ARRAY_SIZE(http_versions), version);
+   if (h_version < 0) {
+   req->version = UH_HTTP_VER_1_0;
+   return CLIENT_STATE_DONE;
+   }
+
+   req->method = proxycl->request.method;
+   req->version = h_version;
+   if (req->version < UH_HTTP_VER_1_1 || req->method == UH_HTTP_MSG_POST ||
+   !conf.http_keepalive)
+   req->connection_close = true;
+   req->code = atoi(code);
+   req->msg = strdup(msg);
+   if (req->code <= 0)
+   goto error;
+
+   return CLIENT_STATE_HEADER;
+
+   error:
+   uh_client_error(cl->proxycl, 502, "Bad Gateway", "Invalid 
response from target\n");
+   return CLIENT_STATE_DONE;
+}
+#endif
+
 static int client_parse_request(struct client *cl, char *data)
 {
struct http_request *req = >request;
@@ -206,10 +254,30 @@ static bool client_init_cb(struct client *cl, char *buf, 
int len)
 
*newline 

Re: [LEDE-DEV] Please enable digest mode for lede-dev

[Arjen de Korte]

Citeren Hannu Nyman :


Please allow users to select to receive lede-dev messages in digests.

The lede-dev mailing list is already rather high volume list and if  
the possible PR discussion messages from Github is also piped here,  
the amount of messages might be rather high.


Devs have disabled the "digest mode" in the mailing list's settings  
and thus users can't select to receive messagess in digest format.  
Please toggle the switch and allow users to receive messages in  
digest format if they so wish.


Is it possible to prevent people from replying to these digest  
messages? I'm seeing this happen a lot on other mailinglist I follow  
and it makes conversation mode almost useless.


Ps. the disabled digest mode might be one reason why there is so  
much actual conversation. Each message arrives separately so it is  
easy to answer. So it might be best if the digest mode is allowed  
but the default is still individual messages.




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

[LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements

[lede]

Hi John,

I haven't tested these changes yet, but is this what you were looking for
in terms of changes to the patches previously as part of the PRs you
commented on?

[PATCH 1/4] [RFC] fstools: block.c: Make static string a const char * instead 
char *
[PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems
[PATCH 3/4] [RFC] fstools: block.c: Use  instead of defining mount 
flags
[PATCH 4/4] [RFC] fstools: block.c: Add ability to mount with ACL and XATTR 
support

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

Re: [LEDE-DEV] running stuff as !root

[Ferry Huberts]

On 18/05/16 11:10, David Lang wrote:

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance
impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was
talked about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not
the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll
point out that if home users are familar with Linux, the odds are good
that it's a flavor of Ubuntu that uses AA rather than Fedora that uses
SELinux. (not worth much because the home user probably hasn't touched
AA or SELinux)


That should not be an argument to do one or the other.
You should ask yourself how far you would want to go in securing a 
router. Personally, I would absolutely love a router with a tight 
SELinux policy since it protects me well from unsavory access from the 
outside.




do all the compressed filesystems support the tagging needed by SELinux?
what about external drives with FAT* or NTFS?


FAT and NTFS do not support it AFAIK, but how is that a problem?
You'd run SELinux on your internal filesystem.

For the compressed filesystems: I don't know, they will probably support 
it if they're good citizen Linux filesystems.





How do you handle the possible need to re-label your files on a
read-only filesystem?



Don't know, but take a look at Android, it has SELinux enabled in 
enforcing mode (the strongest mode).




what is the difference in kernel size (and tool size) between AA and
SELinux?





Don't know.


For clarity (and for weaseling out): I read a snip of the discussion and 
wanted to offer another alternative, so that the discussion could 
consider it.




--
Ferry Huberts

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

Re: [LEDE-DEV] libubox, procd: init process hangs

[Mats Karrman]

On 2016-05-17 17:31, Mats Karrman wrote:


On 2016-05-17 13:29, Felix Fietkau wrote:

I just took a look at the code and uloop's processing of signals looked
a bit racy to me. I've pushed a commit that makes it use signalfd if
available. I also found that waitpid wasn't being retried on signal
interrupt, so I added an extra check there. The changes are in libubox
git, but not in OpenWrt/LEDE yet.
Please test if this fixes your issue.

Thanks,

- Felix

Tried that but no immediate success, but it might have provided
some additional clues. Now the boot hangs early on *every* boot
but after logging in I found something different in the ps list.
There is a Broadcom utility (smd) that is called from one of the
start scripts (S10environment). It's purpose is to set scheduling
priority and cpu affinity for some of the Broadcom proprietary
processes, The smd program handles fork rather ugly. The
parent only loops until it receives SIGCHLD and then exits without
any wait. With the modified libubox I get a zombie smd child and
sleeping smd parent and S11environment (no other zombie).

Not sure exactly how this happened but I got to think about
something written in the wait man page:

"""
If  a parent process terminates, then its "zombie" children (if any)
are adopted by init(8), which automatically performs a wait to
remove the zombies.
"""

Is this wait really (unconditionally) implemented in procd or could
that be what I accomplished with the "forced timeout" patch?

I fixed the ugly fork and got the system to boot once.
Then tried the original libubox with the fixed smd program but
this was not enough to get things working (25 reboots to hang).

Now I'm running reboot tests with your new libubox and fixed smd...

More than 250 reboots without problem :)

Clearly the smd program is broken, but still it doesn't feel good that it
manages to hang the init process. Considering that timing is involved
it's difficult to make any certain conclusions but it seems like having
uloop epoll_wait to time out occasionally isn't such a bad idea?

// Mats


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

Re: [LEDE-DEV] running stuff as !root

[Radu Anghel]

Replying to myself :)

On Wed, May 18, 2016 at 10:53 AM, Radu Anghel  wrote:
>
> step 1. add users to /etc/passwd (in the pre/post-install script
> probably, trying to use same uid/gid as major distributions would be
> nice)
> step 2. add config option for user/group in the relevant /etc/config/ file
> step 3. modify startup script to use the user/group options when
> generating daemon config file
> step 4. ???
> step 5. PROFIT!
>

This approach would also open up some interesting posibilities
(interesting for me at least) like the ability to add non-privileged
users that can perform configuration changes or backups but can't use
sysupgrade.

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was talked 
about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not the 
normal user of LEDE/OpenWRT. For what (little) it's worth, I'll point out that 
if home users are familar with Linux, the odds are good that it's a flavor of 
Ubuntu that uses AA rather than Fedora that uses SELinux. (not worth much 
because the home user probably hasn't touched AA or SELinux)


do all the compressed filesystems support the tagging needed by SELinux? what 
about external drives with FAT* or NTFS?


How do you handle the possible need to re-label your files on a read-only 
filesystem?


what is the difference in kernel size (and tool size) between AA and SELinux?

David Lang

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

Re: [LEDE-DEV] running stuff as !root

[Radu Anghel]

On Wed, May 18, 2016 at 9:25 AM, John Crispin  wrote:
>
> to elaborate, imagine dnsmasq running inside a jailm where ut only
> thinks it is root but is not in reality. also ld-preloading bind and
> connect would allow us to do pretty adavnced stuff like only allowing
> dnsmasq to open certain ports. essentially an acl around the
> bind/connect calls.
>

Doing this with a in-house developed daemon would introduce another
SPOF in the same way as running everyting with the same non-root user.
Imagine a security issue in such a daemon, it would affect *all*
daemons running through it.

This would also duplicate existing functionality (the code for
dropping privileges to a preconfigured user already exists in most
daemons, it is compiled as there is no --without-privileges-code
./configure option). Implementing different users with this approach
can be done in a few easy steps with minor to none added overhead:

step 1. add users to /etc/passwd (in the pre/post-install script
probably, trying to use same uid/gid as major distributions would be
nice)
step 2. add config option for user/group in the relevant /etc/config/ file
step 3. modify startup script to use the user/group options when
generating daemon config file
step 4. ???
step 5. PROFIT!

I understand there are trust issues about this functionality (don't
trust that the daemon really dropped all privileges), in such a case I
would use SELinux. SELinux can be enabled as "permissive" until a
proper policy is created for everything.

There are other things to consider also, because this is supposed to
run on embedded devices with as low as 4M flash space:

- SELinux would increase kernel size, thus making it hard to fit
inside the flash, or even bigger than the fixed kernel partition for
some devices.
- jails, containers and other options discussed require more
memory/CPU/flash space than is probably available on said devices.


Radu

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

Re: [LEDE-DEV] running stuff as !root

[Ferry Huberts]

On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



On 18/05/16 09:25, John Crispin wrote:



On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin 
wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between
until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.




You might just as well switch on SELinux and use the policies that are
already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was talked 
about, you can just declare which ports are allowed.




SELinux configs that Fedora uses have to be so permissive to keep from
breaking too many 'normal' use cases that I really question how valuable
they are.


And this is based on what exactly?
I've been using Fedora ever since SELinux was first enabled and I don't 
see that. Processes are well secured.
If you think about stuff like Firefox, then ok, that one is really hard 
to secure, better run it in a sandbox.

But process that are well-defined in behaviour are well secured.





A SELinux system tuned by an expert is going to be more secure than an
AppArmor system tuned by an expert, SELinux just can do more (at least
right now). But there aren't many experts of that caliber around. A
reasonably competent sysadmin can understand an AppArmor config and
tweak it for their layout without too much effort (once they identify
that AppArmor is blocking what they are trying to do)




Agreed, it is a balance.

However, I must note that I've encountered very few cases where the 
policy had to be tweaked, on my laptops, desktop and most of all servers.


One example of tweaking is when I move a service to a different port.
That is a single command, like (moving the port of the 'cockpit' service):

semanage port -a -t websm_port_t -p tcp "$newport"




My 2 cents :-)






David Lang

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


--
Ferry Huberts

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



On 18/05/16 09:25, John Crispin wrote:



On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.




You might just as well switch on SELinux and use the policies that are
already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full
blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between different 
application configs that you do with SELinux, so you can focus on the specific 
application that you are concerned about.


SELinux configs that Fedora uses have to be so permissive to keep from breaking 
too many 'normal' use cases that I really question how valuable they are.


A SELinux system tuned by an expert is going to be more secure than an AppArmor 
system tuned by an expert, SELinux just can do more (at least right now). But 
there aren't many experts of that caliber around. A reasonably competent 
sysadmin can understand an AppArmor config and tweak it for their layout without 
too much effort (once they identify that AppArmor is blocking what they are 
trying to do)


David Lang

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.


well, between the different namespace options (pid, user, network, filesystem) 
you can have the thing running in the container thinking that it is root and the 
container configuration limit what it can do. This is the bleeding edge of 
containerization, so advanced use cases like you are defining are going to be 
fragile as the kinks get worked out. But there are a lot of people working in 
this problem space right now.


I personally think that the best bet is to ignore the problem for now, but keep 
an eye on the different container projects, try to make them all work on LEDE, 
and as the dust starts to settle, pick the top (or top few) survivors and start 
using them.


Right now some of the namespace types open up as many vulnerabilities as they 
allow you to close.




Another think to keep in mind is that most of these projects allow you to 
package up and containerize individual daemons, but as soon as you start needing 
to have the different things interact with each other (say the container running 
LUCI needs to start configuring the container running asterisk), they get really 
ugly.




And finally, many of the people focusing on these projects are aiming for the 
cloud datacenter market where every machine is ephemeral and is expected to 
disappear and take all data/configs stored on it as it goes. So they all rely on 
some external storage/database setup to hold all that stuff. Not something 
normally available to LEDE type devices running in homes and small offices.



David Lang

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

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 09:49, Etienne Champetier wrote:
> Hi,
> 
> 2016-05-18 9:25 GMT+02:00 John Crispin :
>>
>>
>> On 18/05/2016 09:21, Radu Anghel wrote:
>>> /* sending again because i hit 'reply' instead of 'reply all' :) */
>>>
>>> On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:

 ok, there had been some discussion about building a super daemon that
 runs, then ld-preloading bind() and co and using ubus to transport
 sockets around. using caps or /proc sounds like a good i between until
 such a daemon exists

>>>
>>> Most daemons I know of that need to bind to ports <1024 start as root
>>> and after binding to the port they drop privileges to the privileges
>>> of the user specified in their config file. For those daemons just
>>> adding a user and specifying it in their config file should be enough.
>>> For the daemons that don't need to bind to <1024 just starting them
>>> from their own user account is ok as they don't need additional
>>> privileges.
>>>
>>> For example the dnsmasq daemon has these options:
>>>
>>> # If you want dnsmasq to change uid and gid to something other
>>> # than the default, edit the following lines.
>>> #user=
>>> #group=
>>>
>>> I don't think that integrating such functionality in ubus or some
>>> other LEDE-only super-daemon is a good idea. Config options +
>>> capabilities for those daemons withut such options is a good way of
>>> doing this in my opinion. Also use different users for different
>>> daemons, as others said.
>>
>> to elaborate, imagine dnsmasq running inside a jailm where ut only
>> thinks it is root but is not in reality. also ld-preloading bind and
>> connect would allow us to do pretty adavnced stuff like only allowing
>> dnsmasq to open certain ports. essentially an acl around the
>> bind/connect calls.
>>
>> John
>>
> 
> Capabilities is the way to go.
> Filesystem capabilities are painfull, so we will use process
> capabilities (inherited from procd).
> 
> I've already integrated normal capabilities in ujail, so you can run
> as "reduced" root.
> 
> You can inherit capabilities between non root user (if you have
> capabilities to inherit...) but the program as to do it explicitly,
> so for exemple i could (not yet supported) launch zabbix with
> CAP_NET_RAW and user zabbix, but subprocess of zabbix will not be able
> to use it.
> 
> For subprocess to inherit capabilities without using root user, we
> need to look into ambient capabilities (linux 4.3)
> 
> Cheers
> Etienne
> 

Hi Etienne,

i agree, for now this should be handled via caps. never heard of ambient
ones, will look into that. thanks for the pointer.

John

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

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 09:46, Ferry Huberts wrote:
> 
> 
> On 18/05/16 09:25, John Crispin wrote:
>>
>>
>> On 18/05/2016 09:21, Radu Anghel wrote:
>>> /* sending again because i hit 'reply' instead of 'reply all' :) */
>>>
>>> On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:

 ok, there had been some discussion about building a super daemon that
 runs, then ld-preloading bind() and co and using ubus to transport
 sockets around. using caps or /proc sounds like a good i between until
 such a daemon exists

>>>
>>> Most daemons I know of that need to bind to ports <1024 start as root
>>> and after binding to the port they drop privileges to the privileges
>>> of the user specified in their config file. For those daemons just
>>> adding a user and specifying it in their config file should be enough.
>>> For the daemons that don't need to bind to <1024 just starting them
>>> from their own user account is ok as they don't need additional
>>> privileges.
>>>
>>> For example the dnsmasq daemon has these options:
>>>
>>> # If you want dnsmasq to change uid and gid to something other
>>> # than the default, edit the following lines.
>>> #user=
>>> #group=
>>>
>>> I don't think that integrating such functionality in ubus or some
>>> other LEDE-only super-daemon is a good idea. Config options +
>>> capabilities for those daemons withut such options is a good way of
>>> doing this in my opinion. Also use different users for different
>>> daemons, as others said.
>>
>> to elaborate, imagine dnsmasq running inside a jailm where ut only
>> thinks it is root but is not in reality. also ld-preloading bind and
>> connect would allow us to do pretty adavnced stuff like only allowing
>> dnsmasq to open certain ports. essentially an acl around the
>> bind/connect calls.
>>
> 
> 
> You might just as well switch on SELinux and use the policies that are
> already in-place in Fedora and RedHat/CentOS.
> 
> You then get even stronger protection and run-time performance impact is
> negligible.
> 
the stuff i proposed has not runtime hit. selinux is simple to full
blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.

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

Re: [LEDE-DEV] running stuff as !root

[Etienne Champetier]

Hi,

2016-05-18 9:25 GMT+02:00 John Crispin :
>
>
> On 18/05/2016 09:21, Radu Anghel wrote:
>> /* sending again because i hit 'reply' instead of 'reply all' :) */
>>
>> On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:
>>>
>>> ok, there had been some discussion about building a super daemon that
>>> runs, then ld-preloading bind() and co and using ubus to transport
>>> sockets around. using caps or /proc sounds like a good i between until
>>> such a daemon exists
>>>
>>
>> Most daemons I know of that need to bind to ports <1024 start as root
>> and after binding to the port they drop privileges to the privileges
>> of the user specified in their config file. For those daemons just
>> adding a user and specifying it in their config file should be enough.
>> For the daemons that don't need to bind to <1024 just starting them
>> from their own user account is ok as they don't need additional
>> privileges.
>>
>> For example the dnsmasq daemon has these options:
>>
>> # If you want dnsmasq to change uid and gid to something other
>> # than the default, edit the following lines.
>> #user=
>> #group=
>>
>> I don't think that integrating such functionality in ubus or some
>> other LEDE-only super-daemon is a good idea. Config options +
>> capabilities for those daemons withut such options is a good way of
>> doing this in my opinion. Also use different users for different
>> daemons, as others said.
>
> to elaborate, imagine dnsmasq running inside a jailm where ut only
> thinks it is root but is not in reality. also ld-preloading bind and
> connect would allow us to do pretty adavnced stuff like only allowing
> dnsmasq to open certain ports. essentially an acl around the
> bind/connect calls.
>
> John
>

Capabilities is the way to go.
Filesystem capabilities are painfull, so we will use process
capabilities (inherited from procd).

I've already integrated normal capabilities in ujail, so you can run
as "reduced" root.

You can inherit capabilities between non root user (if you have
capabilities to inherit...) but the program as to do it explicitly,
so for exemple i could (not yet supported) launch zabbix with
CAP_NET_RAW and user zabbix, but subprocess of zabbix will not be able
to use it.

For subprocess to inherit capabilities without using root user, we
need to look into ambient capabilities (linux 4.3)

Cheers
Etienne

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

Re: [LEDE-DEV] running stuff as !root

[Ferry Huberts]

On 18/05/16 09:25, John Crispin wrote:



On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.




You might just as well switch on SELinux and use the policies that are 
already in-place in Fedora and RedHat/CentOS.


You then get even stronger protection and run-time performance impact is 
negligible.




John

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



--
Ferry Huberts

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

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 09:04, David Lang wrote:
> 
> The first question I would have is if we are going to the system users
> in an essentially random order (as needed so two systems with the same
> packages installed in a different order have different user->uid
> mapping) or if we are going to define service accounts distro wide so
> they are always going to be the same.


what would be the pros and cons for either of those ?

John

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 08:09, Daniel Curran-Dickinson wrote:

On 16-05-18 01:05 AM, John Crispin wrote:

Hi,

we had previously started building the infra for running stuff as !root.
so far we have added

* the userid/gid stuff
* acl on ubus

things that i know are missing

* handling network ports < 1024

what am i missing ? can anyone think of other issues we need to address
before we change uid to !root ?



Er, do you mean uid of procd or ubus or everything?  I'm not sure we're
clear on which uid you mean?


ok, my mail that sounded totally obvious to me apparently was hard to
understand.

right now we run $everything as root which is obviously rather daring so
we need to change it to what normal distros do and run stuff as their
own users wherever it makes sense and give those users only the
permissions required.


Ok, that makes a lot of sense. The good news here is that we don't have to start 
off with doing fancy stuff like passing sockets around, playing with 
capabilities to bind to low ports, SELinux/AppArmor, etc. We can start off by 
just copying the sysV init configs that have existed for other distros.


Most of the work is actually going to be in undoing OpenWRT specific configs 
that run everything as root and fall more in line with what the other distros 
are doing.


The first question I would have is if we are going to the system users in an 
essentially random order (as needed so two systems with the same packages 
installed in a different order have different user->uid mapping) or if we are 
going to define service accounts distro wide so they are always going to be the 
same.


David Lang

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

[LEDE-DEV] procd and self-daemonizing processes with no useful foreground option

[Daniel Dickinson]

Hi,

Rather than patching every package that daemonizes itself but doesn't
provide a useful (non-debug mode) option for foregrounding the process
(or not option at all for foreground operation), would it possible to do
as systemd has done and support both a directly supervised instance
(i.e. what it does now where the process is in the foreground and
daemonized by procd) as well as forked processes that daemonize themselves?

I've run into three so far that have this problem, and am thinking there
are probably more I just haven't encountered yet.

This is really the only bit of systemd that I've wished we had (although
"it'd be nice" to replace xinetd too with a .socket like thing).

I think that covers 90% or more of the cases where processes need to be
daemonized and managed.

Regards,

Daniel

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

Re: [LEDE-DEV] Why does multiple instance dnsmasq work with jails but not without?

[Daniel Curran-Dickinson]

On 16-05-18 02:32 AM, John Crispin wrote:
> it probably checks for a pid file or similar to see if it is already
> running. inside a jail it essentially only runs once as it is a
> container. so i would guess its pid file of proc table related.

It is most likely proc table then (I had separate pidfiles, so that
wasn't the issue); I had forgotten jails had a separate process space.

I think avahi-daemon actually does the same thing.

(Although from the looks if it the daemon I'm interested in getting
working on LEDE where mdns wouldn't be sufficient, with the right procd
config, is CUPS, and that's because it dynamically creates entries for
each printer attached, rather than a single service entry (and things
that depend on CUPS mDNS depend on the info in the printer-specific entry)).

Regards,

Daniel

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

Re: [LEDE-DEV] Why does multiple instance dnsmasq work with jails but not without?

[John Crispin]

On 18/05/2016 08:24, Daniel Dickinson wrote:
> Hi all,
> 
> I had a patch that I submitted to the openwrt list sometime back that
> launched multiple instances of dnsmasq, so long as the instances were
> either tied to specific, non-overlapping, interfaces, or used different
> dns port, but at least in the case of different interfaces it only
> worked (to my dismay) if jails were in use.  Without jails only a single
> instance of dnsmasq would start.
> 
> Does anyone know why this is?
> 
> (The use case is to serve a guest vlan with a dnsmasq instance that
> forced the to use the opendns familyshield filter (since the point of
> guest vlan is you don't necessarily know how far to trust the people on
> the guest vlan (for a separate wifi SSID)).
> 
> Regards,
> 
> Daniel

it probably checks for a pid file or similar to see if it is already
running. inside a jail it essentially only runs once as it is a
container. so i would guess its pid file of proc table related.

John

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

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 08:09, Daniel Curran-Dickinson wrote:
> On 16-05-18 01:05 AM, John Crispin wrote:
>> Hi,
>>
>> we had previously started building the infra for running stuff as !root.
>> so far we have added
>>
>> * the userid/gid stuff
>> * acl on ubus
>>
>> things that i know are missing
>>
>> * handling network ports < 1024
>>
>> what am i missing ? can anyone think of other issues we need to address
>> before we change uid to !root ?
>>
> 
> Er, do you mean uid of procd or ubus or everything?  I'm not sure we're
> clear on which uid you mean?

ok, my mail that sounded totally obvious to me apparently was hard to
understand.

right now we run $everything as root which is obviously rather daring so
we need to change it to what normal distros do and run stuff as their
own users wherever it makes sense and give those users only the
permissions required.

John

> ___
> 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] running stuff as !root

[John Crispin]

On 18/05/2016 08:08, David Lang wrote:
> On Wed, 18 May 2016, John Crispin wrote:
> 
>> Hi,
>>
>> we had previously started building the infra for running stuff as !root.
>> so far we have added
>>
>> * the userid/gid stuff
>> * acl on ubus
>>
>> things that i know are missing
>>
>> * handling network ports < 1024
>>
>> what am i missing ? can anyone think of other issues we need to address
>> before we change uid to !root ?
> 
> what things are you trying to run as !root?

services and daemons obviously

> just changing everything to run as user lede (uid 1) instead of root
> (uid 0) doesn't actually buy much, especially if user lede is able to
> administer things https://xkcd.com/1200/
>
> you want to end up running different types of things as different users,
> and there the permissions get more 'interesting'

thanks for the pointer, that was totally not obvious at all ...

> there is a capability you can give to binaries to let them bind to ports
> < 1024, there is also a proc setting you can use to let anything bind to
> ports < 1024.

ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists

> 
> There are various other things that will require capabilities to work
> (including some versions of ping and traceroute), but it's a matter of
> fixing them as you bump into them.

yes, but i'll try those on my journey.

> don't try to make everything run as the same !root user, migrate things
> one (or at least one category) at a time.

thanks for the pointer, that was totally not obvious at all ...

John

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

[LEDE-DEV] Why does multiple instance dnsmasq work with jails but not without?

[Daniel Curran-Dickinson]

Hi all,

I had a patch that I submitted to the openwrt list sometime back that
launched multiple instances of dnsmasq, so long as the instances were
either tied to specific, non-overlapping, interfaces, or used different
dns port, but at least in the case of different interfaces it only
worked (to my dismay) if jails were in use.  Without jails only a single
instance of dnsmasq would start.

Does anyone know why this is?

(The use case is to serve a guest vlan with a dnsmasq instance that
forced the to use the opendns familyshield filter (since the point of
guest vlan is you don't necessarily know how far to trust the people on
the guest vlan (for a separate wifi SSID)).

Regards,

Daniel

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

Re: [LEDE-DEV] running stuff as !root

[Daniel Curran-Dickinson]

On 16-05-18 01:05 AM, John Crispin wrote:
> Hi,
> 
> we had previously started building the infra for running stuff as !root.
> so far we have added
> 
> * the userid/gid stuff
> * acl on ubus
> 
> things that i know are missing
> 
> * handling network ports < 1024
> 
> what am i missing ? can anyone think of other issues we need to address
> before we change uid to !root ?
> 

Er, do you mean uid of procd or ubus or everything?  I'm not sure we're
clear on which uid you mean?

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


Hi,

we had previously started building the infra for running stuff as !root.
so far we have added

* the userid/gid stuff
* acl on ubus

things that i know are missing

* handling network ports < 1024

what am i missing ? can anyone think of other issues we need to address
before we change uid to !root ?


what things are you trying to run as !root?

just changing everything to run as user lede (uid 1) instead of root (uid 0) 
doesn't actually buy much, especially if user lede is able to administer things 
https://xkcd.com/1200/


you want to end up running different types of things as different users, and 
there the permissions get more 'interesting'


there is a capability you can give to binaries to let them bind to ports < 1024, 
there is also a proc setting you can use to let anything bind to ports < 1024.


There are various other things that will require capabilities to work (including 
some versions of ping and traceroute), but it's a matter of fixing them as you 
bump into them.


don't try to make everything run as the same !root user, migrate things one (or 
at least one category) at a time.


David Lang

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