Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. [PATCH v2 1/2] dnsproxy: Send a short response on error
(Patrik Flykt)
2. [PATCH v2 0/2] Stricter handling of DNS requests (Patrik Flykt)
3. Re: Domain name setting error and fix (Patrik Flykt)
4. Re: [PATCH v2 0/2] Stricter handling of DNS requests
(Daniel Wagner)
5. Re: Domain name setting error and fix (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Fri, 25 Aug 2017 14:27:08 +0300
From: Patrik Flykt <[email protected]>
To: [email protected]
Subject: [PATCH v2 1/2] dnsproxy: Send a short response on error
Message-ID: <[email protected]>
On error there is no need to send the whole packet back to the
client, only the basic headers informing of the error. Also check
the length of the buffer, including protocol offsets.
---
src/dnsproxy.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/dnsproxy.c b/src/dnsproxy.c
index 40b4f159..ef91a7cb 100644
--- a/src/dnsproxy.c
+++ b/src/dnsproxy.c
@@ -470,7 +470,7 @@ static void send_cached_response(int sk, unsigned char
*buf, int len,
err, len, dns_len);
}
-static void send_response(int sk, unsigned char *buf, int len,
+static void send_response(int sk, unsigned char *buf, size_t len,
const struct sockaddr *to, socklen_t tolen,
int protocol)
{
@@ -482,21 +482,26 @@ static void send_response(int sk, unsigned char *buf, int
len,
if (offset < 0)
return;
- if (len < 12)
+ if (len < sizeof(*hdr) + offset)
return;
hdr = (void *) (buf + offset);
+ if (offset) {
+ buf[0] = 0;
+ buf[1] = sizeof(*hdr);
+ }
debug("id 0x%04x qr %d opcode %d", hdr->id, hdr->qr, hdr->opcode);
hdr->qr = 1;
hdr->rcode = ns_r_servfail;
+ hdr->qdcount = 0;
hdr->ancount = 0;
hdr->nscount = 0;
hdr->arcount = 0;
- err = sendto(sk, buf, len, MSG_NOSIGNAL, to, tolen);
+ err = sendto(sk, buf, sizeof(*hdr) + offset, MSG_NOSIGNAL, to, tolen);
if (err < 0) {
connman_error("Failed to send DNS response to %d: %s",
sk, strerror(errno));
--
2.11.0
------------------------------
Message: 2
Date: Fri, 25 Aug 2017 14:27:07 +0300
From: Patrik Flykt <[email protected]>
To: [email protected]
Subject: [PATCH v2 0/2] Stricter handling of DNS requests
Message-ID: <[email protected]>
Hi,
Here is v2, now with various sized explicitely stated.
Cheers,
Patrik
Patrik Flykt (2):
dnsproxy: Send a short response on error
dnsproxy: Be more strict with incoming DNS requests
src/dnsproxy.c | 78 ++++++++++++++++++++++++++++++++++++----------------------
1 file changed, 49 insertions(+), 29 deletions(-)
--
2.11.0
------------------------------
Message: 3
Date: Fri, 25 Aug 2017 14:32:51 +0300
From: Patrik Flykt <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Neven Sajko <[email protected]>, [email protected]
Subject: Re: Domain name setting error and fix
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2017-08-25 at 12:50 +0200, Daniel Wagner wrote:
> Patrik Flykt <[email protected]> writes:
>
> > On Fri, 2017-08-25 at 11:40 +0200, Daniel Wagner wrote:
> > > """
> > > To summarize: CAP_SYS_ADMIN has become the new root. If the goal
> > > of
> > > capabilities is to limit the power of privileged programs to be
> > > less
> > > than root, then once we give a program CAP_SYS_ADMIN the game is
> > > more
> > > or less over. That is the manifest problem revealed from the
> > > above
> > > analysis. However, if we look further, there is evidence of an
> > > additional problem, one that lies in the Linux development model.
> > > """
> >
> > Indeed... Do we need to set the domainname in the first place? Or
> > hostname? Right now I don't remember which issues setting the
> > domainname were supposed to solve. Setting the hostname probably
> > fails
> > as well(?), but keeping the same hostname makes me feel at home
> > independent of network :-)
>
> IIRC it was added to allow to configure embedded devices via DNS. I
> know
> the feeling of hostname changing. Luckely there is
> AllowHostnameUpdates=false :)
>
> So do we agree on dropping the capabilities attempt?
If you ask me I rather keep off the root privilegies and fail with the
host and domain names. But people can depend on this feature, so...
Keep the line, but comment it out in the service file? With perhaps an
explanation attached on a line above?
Cheers,
Patrik
------------------------------
Message: 4
Date: Fri, 25 Aug 2017 14:00:02 +0200
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH v2 0/2] Stricter handling of DNS requests
Message-ID: <[email protected]>
Content-Type: text/plain
Hi Patrik,
Patrik Flykt <[email protected]> writes:
> Hi,
>
> Here is v2, now with various sized explicitely stated.
Excellent. Both patches applied.
Thanks,
Daniel
------------------------------
Message: 5
Date: Fri, 25 Aug 2017 14:02:40 +0200
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: Domain name setting error and fix
Message-ID: <[email protected]>
Content-Type: text/plain
Patrik Flykt <[email protected]> writes:
> On Fri, 2017-08-25 at 12:50 +0200, Daniel Wagner wrote:
>> Patrik Flykt <[email protected]> writes:
>>
>> > On Fri, 2017-08-25 at 11:40 +0200, Daniel Wagner wrote:
>> > > """
>> > > To summarize: CAP_SYS_ADMIN has become the new root. If the goal
>> > > of
>> > > capabilities is to limit the power of privileged programs to be
>> > > less
>> > > than root, then once we give a program CAP_SYS_ADMIN the game is
>> > > more
>> > > or less over. That is the manifest problem revealed from the
>> > > above
>> > > analysis. However, if we look further, there is evidence of an
>> > > additional problem, one that lies in the Linux development model.
>> > > """
>> >
>> > Indeed... Do we need to set the domainname in the first place? Or
>> > hostname? Right now I don't remember which issues setting the
>> > domainname were supposed to solve. Setting the hostname probably
>> > fails
>> > as well(?), but keeping the same hostname makes me feel at home
>> > independent of network :-)
>>
>> IIRC it was added to allow to configure embedded devices via DNS. I
>> know
>> the feeling of hostname changing. Luckely there is
>> AllowHostnameUpdates=false :)
>>
>> So do we agree on dropping the capabilities attempt?
>
> If you ask me I rather keep off the root privilegies and fail with the
> host and domain names. But people can depend on this feature, so...
>
> Keep the line, but comment it out in the service file? With perhaps an
> explanation attached on a line above?
Sounds like a plan. Usally, the systemd service file needs to be
tweaked to fit into distro.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 22, Issue 21
***************************************
