Re: First release of LibreSSL portable is available.
Hi, On Fri, Jul 11, 2014 at 12:21:12PM -0600, Bob Beck wrote: > The first release of LibreSSL portable has been released. LibreSSL > can be found in the LibreSSL directory of your favorite OpenBSD mirror. > > http://ftp.openbsd.org/pub/OpenBSD/LibreSSL has it, and other mirrors sounds great! Would you mind publishing checksums & stuff for that? TIA! Kind regards, --Toni++
Re: LibreSSL 2.0.1 released - installation extra_mode
Hi Jan, On Sun, Jul 13, 2014 at 08:30:38PM +0200, Jan Engelhardt wrote: > On Sunday 2014-07-13 13:07, Bob Beck wrote: > >We have released an update, LibreSSL 2.0.1 > >As noted before, we welcome feedback from the broader community. > > Something that I have noticed is that the shared libraries generated > by the portable libressl tarball are installed to their final > location (in DESTDIR) with odd mode 644. what's odd about this mode? On my Debian box, I have, for the OpenSSL lib: $ l /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 -rw-r--r-- 1 root root 391928 Jun 15 13:36 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 Kind regards, --Toni++
Re: pxeboot hd0a:/bsd tries to nfs_boot...
Hi, On Mon, 28.06.2010 at 13:52:45 -0600, Nick Bender wrote: > First the problem. Once a machine is automatically installed we want to > change things so that it will boot from the hard drive. We have two > possibilities. ;} > The first is to arrange so that the machine will boot first from the network > and then from the hard drive. Once the install succeeds remove the > dhcpd.conf entry and allow the pxeboot to timeout with no response. > Works fine with only a small delay for the timeout. The downside of this is that it is (imho) mostly a manual process. > The second possibility is to allow the machine to pxeboot but tell it to boot > from the hard drive with the newly installed system. This would work if the pxeboot could support this. pxelinux does something like this. Maybe you want to take a look at it. Kind regards, --Toni++
Re: Fully Automated OpenBSD Installation (Version 2)
On Tue, 30.09.2008 at 09:04:37 +0100, Stuart Henderson wrote: > On 2008/09/29 22:18, Nick Bender wrote: > > + export DONEPROFILE > + export DONEPROFILE=YES > there's 13 bytes, > + [ -f /install.netboot ] && . /install.netboot > and another 12. Does it really matter, or is CD space that much of a scarcity, too? -- Kind regards, --Toni++
Re: Fully Automated OpenBSD Installation (Version 2)
Hi, On Wed, 09.09.2009 at 11:29:28 +0100, Stuart Henderson wrote: > On 2009/09/09 12:22, Toni Mueller wrote: > > On Tue, 30.09.2008 at 09:04:37 +0100, Stuart Henderson > > wrote: > > > On 2008/09/29 22:18, Nick Bender wrote: > > > > + export DONEPROFILE > > > + export DONEPROFILE=YES > > > there's 13 bytes, > > > + [ -f /install.netboot ] && . /install.netboot > > > and another 12. > > > > Does it really matter, or is CD space that much of a scarcity, too? > > Not CD space, space on the floppy images. And yes, it is scarce. sorry, my bad. Using less verbose file and variable names might help with the space issue. :| Like in [ -f /inst.nb ] && . /inst.nb (16 characters less than the version shown above) -- Kind regards, --Toni++
4.6 compile messages: Do I have to worry?
Hi, today I compiled 4.6-stable from source on an amd64 machine, and got a lot of error messages like this (sample): About 20 or so of these: lint -hx -I/usr/src/lib/libm/arch/amd64 -I/usr/src/lib/libm/src -I/usr/src/lib/libm/src/ld80 -i /usr/src/lib/libm/src/s_conj.c /usr/include/complex.h:43: syntax error /usr/include/complex.h:44: syntax error /usr/include/complex.h:45: syntax error /usr/include/complex.h:46: syntax error /usr/include/complex.h:47: syntax error And about 5 or so of these: lint -hx -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src -I/usr/src/lib/libssl/crypto/../src/crypto -I/usr/src/lib/libssl/crypto/obj -DMD5_ASM -DSHA1_ASM -DOPENSSL_CPUID_OBJ -i /usr/src/lib/libssl/crypto/../src/crypto/bn/asm/x86_64-gcc.c /usr/src/lib/libssl/src/crypto/bn/asm/x86_64-gcc.c:108: syntax error /usr/src/lib/libssl/src/crypto/bn/asm/x86_64-gcc.c:108: syntax error /usr/src/lib/libssl/src/crypto/bn/asm/x86_64-gcc.c:108: syntax error /usr/src/lib/libssl/src/crypto/bn/asm/x86_64-gcc.c:108: warning: high may be used before set /usr/src/lib/libssl/src/crypto/bn/asm/x86_64-gcc.c:109: syntax error /usr/src/lib/libssl/src/crypto/bn/asm/x86_64-gcc.c:109: syntax error /usr/src/lib/libssl/src/crypto/bn/asm/x86_64-gcc.c:109: cannot recover from previous errors The compile appears to complete ok, but these messages don't seem right to me. But then, they're "only" lint messages... TIA! Kind regards, --Toni++
Re: UTF-8 and locale support
Hello, On Thu, 17.12.2009 at 12:43:33 +0100, Artur Litwinowicz wrote: >I would like to ask about potential plans regarding UTF-8 in locales > support. ;} >The problem starts when I am trying to create PostgreSQL cluster The problem manifests itself on many other occasions as well. > Please let me know if is any solution for this problem exists or in the > future that feature will be available :) This feature will be available once someone sits down and writes the code. I though I was that someone, several weeks/months ago, but haven't made any progress. Instead, Jordi Beltran Creix has, to the best of my knowledge, done groundbreaking work in this direction. Kind regards, --Toni++
bsd.dep.mk: suggested change
Hello,
I'd like "make tags" to be more verbose. Esp. I'd like to see data
structures and macros being included:
Index: bsd.dep.mk
===
RCS file: /cvs/src/share/mk/bsd.dep.mk,v
retrieving revision 1.8
diff -u -r1.8 bsd.dep.mk
--- bsd.dep.mk 24 Mar 2008 16:39:13 - 1.8
+++ bsd.dep.mk 12 Mar 2010 17:23:08 -
@@ -39,7 +39,7 @@
.if !target(tags)
. if defined(SRCS)
tags: ${SRCS} _SUBDIRUSE
- -cd ${.CURDIR}; ${CTAGS} -f /dev/stdout ${.ALLSRC:N*.h} | \
+ -cd ${.CURDIR}; ${CTAGS} -f /dev/stdout -d -t ${.ALLSRC:N*.h} | \
sed "s;\${.CURDIR}/;;" > tags
. else
tags:
TIA!
Kind regards,
--Toni++
Re: suggested patch to httpd.conf in base
On Fri, 12.03.2010 at 13:28:07 -0700, kj...@pintday.org wrote: > > Very good suggestion, indeed. -20 I'm impartial, though, as I don't use the default configuration, anyway. I think it's rather a non-issue. > > Especially, if someone has a 'dangerous' file, a PHP Shell for instance, > > (a perfect example: > > http://mgeisler.net/downloads/phpshell/phpshell-1.7.tar.gz) > > inside such a directory. (Or even maybe a simple file uploader, that will > > help the attacker to upload such 'shell-over-http' files.) > > Also, think "emacs-turdfile". Have any config.php~ lying around? > > or index.php~? > > Are you SURE? Yes, I am SURE. Reason: Whoever directly edits files in his or her web tree, is begging for trouble, anyway (imho), eg. resulting in famous websites telling me highly interesting stories like: "/var/www/some/stinking.php: could not contact mysql at bogusserver" (in the less-dangerous cases). I'd say that you generally need a 'development' server, no matter what, where you can have version control, build scripts etc.pp, and a Makefile that has an appropriate target for deployment, so you can go into your development area and say 'make' to put your latest version of anything online. Without cruft, recording a known (good?) state along the way, and a way to undo all of this, or prove to third parties that something was or was not online at some point in time. Having a development server can be as cheap as a virtual host with "different" access restrictions, which points to a different directory, out of reach for the regular web server, so there is really no reason for not having it. Btw, the case with emacs-turdfiles could also be solved by providing a suitable IndexIgnore statement in the configuration. Kind regards, --Toni++
Re: uvm_map improvements
Hi, On Fri, 26.02.2010 at 00:31:35 -0700, Theo de Raadt wrote: > space when it is under high contention. But there is a massively > understated benefit that comes from filling the address space with > unallocated gaps. The gaps, though only on a page boundary, are > finding a lot of bugs. LOTS OF THEM. It is also crashing security > sensitive programs before they come under control. Unfortunately the > finding finding a middle ground in the VM system is a complex problem. stupid idea, perhaps, but would it be possible to recycle the idea of having some sort of canaries at the end of *each* page, thus disposing of the need to have guard pages? Or would that be too costly? > right next to each other. Every day, I will prefer an application > that crashes often (so that it can be fixed, or discarded) over one > that is encouraged by libc to cause random and late-detected > corruption. +100 Kind regards, --Toni++
hacking pfkey: a few questions
Hello, I'm currently hacking on /usr/src/sys/net/pfkey* because I urgently need to prevent the kernel from installing SAs with the value "default" for both sides. In case I got the terminology wrong, I need to prevent this situation, as it brings down networking completely: > 0/00 0/00 0 gatewayIP/50/use/in > 0/00 0/00 0 gatewayIP/50/require/out Or, as shown in 4.6 by ipsecctl: ... flow esp in from 172.18.100.139 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32 dstid uf...@example.com type use flow esp out from 0.0.0.0/0 to 172.18.100.139 peer 87.186.99.179 srcid gatewayip/32 dstid uf...@example.com type require flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32 dstid uf...@example.com type use flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32 dstid uf...@example.com type require ... I'm trying to prevent the two flows flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32 dstid uf...@example.com type use flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32 dstid uf...@example.com type require from getting established. It would be kind if you could tell me whether I'm reading the code correctly so far: In pfkeyv2_parsemessage.c's int pfkeyv2_parsemessage(void *p, int len, void **headers), p and len are input parameters, and headers is an output parameter. In pfkeyv2.c, int pfkeyv2_send(struct socket *socket, void *message, int len) is the central place where all messages that eg. isakmpd might send to the kernel, pass through. That's what the comment suggests. I'm thinking about putting a check after this statement: smsg = (struct sadb_msg *) headers[0]; in the function pfkeyv2_send() (around line 913) that makes the function print an error message and stop processing if the 'message' argument would lead to the creation of a flow like the one shown above. It would be nice if someone could make a short statement about what the different names are for, eg. what's the difference between SADB_EXT_ADDRESS_SRC and SADB_X_EXT_SRC_FLOW, or more generally, what the '_X' in the name should tell me. I'd also be very grateful if you could tell which message types I should be looking at, out of the list of #defines below this #define in sys/net/pfkeyv2.h: #define _OPENBSD_IPSEC_API_VERSION 2 TIA! Kind regards, --Toni++
isakmpd: tiny patch
Hello,
while playing with isakmpd, I found that it would be nice to have a
complement for the "isakmpd: exiting" log entry.
Index: isakmpd.c
===
RCS file: /cvs/src/sbin/isakmpd/isakmpd.c,v
retrieving revision 1.97
diff -u -r1.97 isakmpd.c
--- isakmpd.c 12 May 2008 19:15:02 - 1.97
+++ isakmpd.c 7 Apr 2010 17:16:47 -
@@ -398,6 +398,7 @@
log_to(stderr);
parse_args(argc, argv);
log_init(debug);
+ log_print("isakmpd: starting");
/* Open protocols and services databases. */
setprotoent(1);
Kind regards,
--Toni++
Re: isakmpd: tiny patch
Hi, On Thu, 08.04.2010 at 07:24:26 +0100, Mark Lumsden wrote: > The behaviour your diff introduces isn't without precedence. I'm sorry, but I don't understand what you want to say. > Some daemons do this when starting, some don't. The patch will make isakmpd generate a log entry when it starts. For me, usually running with high levels of debugging, this makes it easier to find the places in the log files where isakmpd starts. I am under the impression that the patch has no negative side effects. I just checked, but on amd64, it doesn't even increase the size of the binary. Kind regards, --Toni++
[patch] Re: hacking pfkey: a few questions
Hi,
I've created a rough patch that should fix the immediate problem, but
is certainly far from perfect (yet). Things to note:
* No IPv6 support (I have no clue).
* No useful error messages - I want to log data about the offending
site, so admins can go after them.
* For some reason I don't yet understand, logging the IP numbers does
not work properly. While the correct IP numbers are logged in hex
code, the same string is emitted for all three IP numbers,
representing the first IP number passed.
* The natural place to emit an error message should be import_flows(),
but I would need to pass some other structure (which?) in for the
sake of generating an error message, AND redo the whole subsystem to
accommodate a non-void import_flow(). Smells like bad architecture...
The patch applies to /usr/src/sys/net. I have it running on one of my
machines, and intend to deploy it on others as well.
Comments and improvements are MUCH appreciated!
--
Kind regards,
--Toni++
Index: pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.119
diff -u -r1.119 pfkeyv2.c
--- pfkeyv2.c 9 May 2008 15:48:15 - 1.119
+++ pfkeyv2.c 11 Apr 2010 17:46:19 -
@@ -131,6 +131,138 @@
extern struct pool ipsec_policy_pool;
+
+/*
+ * DEBUGGING FUNCTIONS
+ */
+
+#define ON_PFKEY_DEBUG 1
+
+#ifdef ON_PFKEY_DEBUG
+
+/* Here are the prototypes for these purely internal functions: */
+
+int on_pfkey_check_tdb(struct tdb *, const char *);
+void on_pfkey_print_sadb_msg(struct sadb_msg *, const char *);
+
+int on_pfkey_check_flow(struct sockaddr_encap *, struct sockaddr_encap *);
+void on_pfkey_log_errors(struct sadb_msg *);
+
+
+/*
+ * on_pfkey_check_flow()
+ *
+ * Checks for the flows for occurrences of "0/0 -> 0/0".
+ *
+ * Return values:
+ * 0: ok
+ * 1: illegal flow detected
+ *
+ * Should be "bool" instead of "int" if we had it...
+ */
+
+int
+on_pfkey_check_flow(struct sockaddr_encap *flow, struct sockaddr_encap
*flowmask)
+{
+ struct in_addr *src = &flow->Sen.Sip4.Src;
+ struct in_addr *dst = &flow->Sen.Sip4.Dst;
+ struct in_addr *srcmask = &flowmask->Sen.Sip4.Src;
+ struct in_addr *dstmask = &flowmask->Sen.Sip4.Dst;
+
+ if (flow->sen_type == SENT_IP6) {
+ printf( "on_pfkey_check_flow(): can't handle the IPv6 case yet,
pretending everything's ok\n");
+ return 0;
+ }
+
+ if ( src->s_addr == (in_addr_t) 0L
+ && dst->s_addr == (in_addr_t) 0L
+ && srcmask->s_addr == (in_addr_t) 0L
+ && dstmask->s_addr == (in_addr_t) 0L)
+ return 1;
+
+ return 0;
+}
+
+void on_pfkey_log_errors(struct sadb_msg *smsg)
+{
+ /* Improve on that ASAP: */
+ printf("Illegal flow detected in message %016lx\n", smsg);
+}
+
+
+/*
+ * int on_pfkey_check_tdb(tdb *newsa, const char *f)
+ *
+ * This function is intended to check for source and destination
+ * addresses of flows being zero. This leaves to complete loss of
+ * connectivity.
+ *
+ * The function generates log entries for things it deems dubious.
+ *
+ * Input parameters:
+ * newsa - the to-be new SA
+ * f - a label, may be NULL, used for log entries
+ *
+ * Return value:
+ * 0: newsa is ok
+ * 1: otherwise
+ */
+
+
+int
+on_pfkey_check_tdb(struct tdb *newsa, const char *f) {
+ char *label = "on_pfkey_check_tdb";
+ union sockaddr_union *src, *dst, *proxy;
+
+ if (f && *f)/* label passed */
+ label = (char *)f;
+
+ /* So far, only print all stuff, do nothing: */
+ src = &newsa->tdb_src;
+ dst = &newsa->tdb_dst;
+ proxy = &newsa->tdb_proxy;
+
+ printf("on_pfkey_check_tdb(tdb at %0lx) families: src=%d, dst=%d,
proxy=%d\n",
+ newsa,
+ src->sa.sa_family,
+ dst->sa.sa_family,
+ proxy->sa.sa_family);
+
+ printf("on_pfkey_check_tdb(tdb at %016lx) addresses: src=%s (%08lx),
dst=%s (%08lx), proxy=%s (%08lx)\n",
+ newsa,
+ inet_ntoa(src->sin.sin_addr),
+ src->sin.sin_addr,
+ inet_ntoa(dst->sin.sin_addr),
+ dst->sin.sin_addr,
+ inet_ntoa(proxy->sin.sin_addr),
+ proxy->sin.sin_addr);
+
+ return on_pfkey_check_flow(&newsa->tdb_filter, &newsa->tdb_filtermask);
+}
+
+
+
+void
+on_pfkey_print_sadb_msg(struct sadb_msg *m, const char *f) {
+ char *label = "on_pfkey_print_sadb_msg";
+
+ if (f && *f)/* label passed */
+ label = (char *)f;
+
+ printf("%s(): received message: sadb_msg { version: %u, type: %u,
errno: %u, satype: %u, len: %u, reserved: %u, seq: %u, pid: %u }\n",
+ label,
+ m->sadb_msg_version,
+ m->sadb_msg_type,
+ m->sadb_msg_errno,
+ m->sadb_msg_satype,
+ m->sadb_msg_len,
+ m->sadb_msg_reserved,
+ m->sadb_msg_seq,
+
Re: [patch] Re: hacking pfkey: a few questions
Hi Patrick, On Sun, 11.04.2010 at 11:58:54 -0700, patrick keshishian wrote: > inet_ntoa will return pointer to a static buffer. Each call > TO IT Will override thsi buffer with the new IP info. I already suspected something like this, but this behaviour is not documented in the man page. :( I'll adapt the code to fix this. > own local buffers and use those in your "log" statement(s). Implementing proper logging, instead of simply using printf(), is also on my agenda further down the road. Kind regards, --Toni++
Re: [patch] Re: hacking pfkey: a few questions
Hi, On Mon, 12.04.2010 at 06:54:31 +0200, Bret S. Lambert wrote: > On Sun, Apr 11, 2010 at 01:43:11PM -0700, patrick keshishian wrote: > > On Sun, Apr 11, 2010 at 09:40:45PM +0200, Toni Mueller wrote: > > > I already suspected something like this, but this behaviour is not > > > documented in the man page. > > > > Look at the very bottom of the man page: > > $ man 9 inet_ntoa > man: no entry for inet_ntoa in section 9 of the manual. Patrick is right, though. The behaviour is described under the BUGS section of the man page, which I happened to overlook: $ man inet_ntoa ... The string returned by inet_ntoa() resides in a static memory area. OpenBSD 4.6December 9, 2008 4 $ Kind regards, --Toni++
Re: [patch] Re: hacking pfkey: a few questions
Hi,
with your comments, I have produceds a second version of the patch,
which includes the following changes:
On Sun, 11.04.2010 at 20:47:38 +0200, Toni Mueller
wrote:
> * No IPv6 support (I have no clue).
* tried to add IPv6 support
* Logging is still not very useful, but at least it does now use
syslog's log() instead of stdio's printf().
The patch applies to /usr/src/sys/net. I have it running on one of my
machines, and intend to deploy it on others as well.
Comments and improvements are MUCH appreciated!
--
Kind regards,
--Toni++
Index: pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.119
diff -u -r1.119 pfkeyv2.c
--- pfkeyv2.c 9 May 2008 15:48:15 - 1.119
+++ pfkeyv2.c 12 Apr 2010 11:40:59 -
@@ -78,6 +78,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -131,6 +132,148 @@
extern struct pool ipsec_policy_pool;
+
+/*
+ * DEBUGGING FUNCTIONS
+ */
+
+#define ON_PFKEY_DEBUG 1
+
+#ifdef ON_PFKEY_DEBUG
+
+/* Here are the prototypes for these purely internal functions: */
+
+int on_pfkey_check_tdb(struct tdb *, const char *);
+void on_pfkey_print_sadb_msg(struct sadb_msg *, const char *);
+
+int on_pfkey_check_flow(struct sockaddr_encap *, struct sockaddr_encap *);
+void on_pfkey_log_errors(struct sadb_msg *);
+
+
+/*
+ * on_pfkey_check_flow()
+ *
+ * Checks for the flows for occurrences of "0/0 -> 0/0".
+ *
+ * Return values:
+ * 0: ok
+ * 1: illegal flow detected
+ *
+ * Should be "bool" instead of "int" if we had it...
+ */
+
+int
+on_pfkey_check_flow(struct sockaddr_encap *flow, struct sockaddr_encap
*flowmask)
+{
+ int rval = 0;
+
+ switch (flow->sen_type) {
+ case SENT_IP6:
+ if (IN6_IS_ADDR_UNSPECIFIED(&(flow->Sen.Sip6.Src))
+ && IN6_IS_ADDR_UNSPECIFIED(&(flow->Sen.Sip6.Src))
+ && IN6_IS_ADDR_UNSPECIFIED(&(flowmask->Sen.Sip6.Src))
+ && IN6_IS_ADDR_UNSPECIFIED(&(flowmask->Sen.Sip6.Src)))
+ rval = 1;
+ break;
+ case SENT_IP4:
+ if ( flow->Sen.Sip4.Src.s_addr == INADDR_ANY
+ && flow->Sen.Sip4.Src.s_addr == INADDR_ANY
+ && flowmask->Sen.Sip4.Src.s_addr == INADDR_ANY
+ && flowmask->Sen.Sip4.Src.s_addr == INADDR_ANY)
+ rval = 1;
+
+ break;
+ }
+ return rval;
+}
+
+void on_pfkey_log_errors(struct sadb_msg *smsg)
+{
+ /* Improve on that ASAP: */
+ log(LOG_WARNING, "Illegal flow detected in message %016lx\n", smsg);
+}
+
+
+/*
+ * int on_pfkey_check_tdb(tdb *newsa, const char *f)
+ *
+ * This function is intended to check for source and destination
+ * addresses of flows being zero. This leaves to complete loss of
+ * connectivity.
+ *
+ * The function generates log entries for things it deems dubious.
+ *
+ * Input parameters:
+ * newsa - the to-be new SA
+ * f - a label, may be NULL, used for log entries
+ *
+ * Return value:
+ * 0: newsa is ok
+ * 1: otherwise
+ */
+
+
+int
+on_pfkey_check_tdb(struct tdb *newsa, const char *f) {
+ char *label = "on_pfkey_check_tdb";
+ union sockaddr_union *src, *dst, *proxy;
+
+ char s_addr[INET6_ADDRSTRLEN];
+ char d_addr[INET6_ADDRSTRLEN];
+ char p_addr[INET6_ADDRSTRLEN];
+
+ if (f && *f)/* label passed */
+ label = (char *)f;
+
+ /* So far, only print all stuff, do nothing: */
+ src = &newsa->tdb_src;
+ dst = &newsa->tdb_dst;
+ proxy = &newsa->tdb_proxy;
+
+ log(LOG_DEBUG, "on_pfkey_check_tdb(tdb at %0lx) families: src=%d,
dst=%d, proxy=%d\n",
+ newsa,
+ src->sa.sa_family,
+ dst->sa.sa_family,
+ proxy->sa.sa_family);
+
+ strncpy(s_addr, inet_ntoa(src->sin.sin_addr), INET6_ADDRSTRLEN);
+ strncpy(d_addr, inet_ntoa(dst->sin.sin_addr), INET6_ADDRSTRLEN);
+ strncpy(p_addr, inet_ntoa(proxy->sin.sin_addr), INET6_ADDRSTRLEN);
+
+ log(LOG_DEBUG,
+ "on_pfkey_check_tdb(tdb at %016lx) addresses: src=%s (%08lx),
dst=%s (%08lx), proxy=%s (%08lx)\n",
+ newsa,
+ s_addr, src->sin.sin_addr,
+ d_addr, dst->sin.sin_addr,
+ p_addr, proxy->sin.sin_addr);
+
+ return on_pfkey_check_flow(&newsa->tdb_filter, &newsa->tdb_filtermask);
+}
+
+
+
+void
+on_pfkey_print_sadb_msg(struct sadb_msg *m, const char *f) {
+ char *label = "on_pfkey_print_sadb_msg";
+
+ if (f && *f)/* label passed */
+ label = (char *)f;
+
+ log(LOG_DEBUG,
+ "%s(): received message: sadb_m
Re: [patch] Re: hacking pfkey: a few questions
Hi, On Mon, 12.04.2010 at 09:37:18 +0200, Toni Mueller wrote: > On Mon, 12.04.2010 at 06:54:31 +0200, Bret S. Lambert > wrote: > > $ man 9 inet_ntoa > > man: no entry for inet_ntoa in section 9 of the manual. > > Patrick is right, though. I have to retract this statement after seeing that inet_ntoa() is described only in section 3, which seemingly may or may not apply to kernel space (but I don't know when, or which). Sorry. -- Kind regards, --Toni++
Re: [patch] Re: hacking pfkey: a few questions
Hi Damien,
On Tue, 13.04.2010 at 12:10:27 +1000, Damien Miller wrote:
> On Mon, 12 Apr 2010, Toni Mueller wrote:
> > with your comments, I have produceds a second version of the patch,
> > which includes the following changes:
>
> IPsec isn't really my area, but some questions:
>
> 1) Why are these flows "illegal"? 0/0 -> 0/0 seems like it might have a
> use as a shorthand for "tunnel absolutely everything".
that is not quite true in practice. Please consider the following
scenario which exhibits the problem that I'm trying to solve:
"gatewayip" is the IP of an OpenBSD gateway, with this topology:
company lan --- OpenBSD gateway --- Internet --- road warrior (eg. at
87.186.99.179)
The following is an exerpt of 'ipsecctl -s a' on the OpenBSD gateway:
Working:
flow esp in from 172.18.100.139 to 0.0.0.0/0 peer 87.186.99.179 srcid
gatewayip/32 dstid uf...@example.com type use
flow esp out from 0.0.0.0/0 to 172.18.100.139 peer 87.186.99.179 srcid
gatewayip/32 dstid uf...@example.com type require
Broken:
---
flow esp in from 172.18.100.139 to 0.0.0.0/0 peer 87.186.99.179 srcid
gatewayip/32 dstid uf...@example.com type use
flow esp out from 0.0.0.0/0 to 172.18.100.139 peer 87.186.99.179 srcid
gatewayip/32 dstid uf...@example.com type require
flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32
dstid uf...@example.com type use
flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32
dstid uf...@example.com type require
I was alerted to the option of getting the two lower two flows (0/0 -
0/0) blocked by using a filter entry in isakmpd.policy, but was so far
unable to get that to work. The documentation is imho a bit unclear
about this, and I can't judge whether I did something really wrong with
the configuration, or whether this is a glitch in the implementation of
isakmpd, or a behaviour mandated by some of the standards.
Now, from the road warrior's end, the first configuration mentioned
above illustrates the situation where the road warrior sends *all*
traffic towards the gateway, no matter what. This is ok, of course, and
illustrates that there is no operational requirement to have such a
"shorthand". On the other hand, though (as stated), I was unable to
prevent the gateway from installing these bogus flows which result in
the _gateway_ considering the road warrior as _its_ default gateway,
which is highly broken, of course, and not only breaks _all_other_
connectivity with the gateway, once it occurs, but also suddenly allows
the road warrior to see all traffic that the gateway might be
transferring, which could (imho: certainly) result in the road warrior
to steal information.
The status quo is that I cannot stop a user on the other side to
completely break the routing on the gateway, which is completely
unacceptable.
I have created workarounds, and my patch so far prevents such users from
establishing bogus flows, but that's about it - not the desired state of
affairs.
> 2) Why are you implementing this in the kernel instead of isakmpd?
I may be looking at iskampd, too, but since I consider this to be
dangerous/broken behaviour by the kernel, I wanted to plug it right
there, so no user space application can insert such bogus flows into the
kernel.
> 3) Why are you implementing this at all? Doesn't isakmpd have mechanisms
> to prevent peers from creating undesired flows?
I didn't see any. Consider this section from isakmpd.policy(5):
remote_filter, local_filter, remote_id
When the corresponding filter_type specifies an address range or
subnet, these are set to the upper and lower part of the address
space separated by a dash ('-') character (if the type specifies
a single address, they are set to that address).
For FQDN and User FQDN types, these are set to the respective
string. For Key ID, these are set to the hexadecimal
representation of the associated byte string (lower-case letters
used) if the Key ID payload contains non-printable characters.
Otherwise, they are set to the respective string.
For ASN1 DN, these are set to the text encoding of the
Distinguished Name in the payload sent or received. The format
is the same as that used in the Licensees field.
This, together with the description of the other "filter_*" statements,
suggests that I cannot have an ID of UFQDN and a filter of IPV4_ADDR,
but only ID and filters of the same type. If this understanding is
correct then it would even be MUCH harder to do this in isakmpd while
still allowing everyone with his own version of isakmpd to still install
as many broken flows as he likes.
Kind regards,
--Toni++
Re: isakmpd: tiny patch
On Thu, 08.04.2010 at 08:52:12 +0100, Mark Lumsden wrote: > You want a yay? Give me a yay: > > http://marc.info/?l=openbsd-tech&m=127071264614038&w=2 > > aka: disklabel - 'P' option Ok, here you are: "yay"... > fairs fair. ?? Kind regards, --Toni++
isakmpd & policy, was: Re: [patch] Re: hacking pfkey: a few questions
Hi, [ still appropriate for tech@ ? ] [ Cc: list clipped - we are all on tech@, anyway, aren't we? ] On Tue, 13.04.2010 at 11:10:00 +0100, Stuart Henderson wrote: > flow esp in from 0.0.0.0/0 to somenetwork/24 type bypass > flow esp out from somenetwork/24 to 0.0.0.0/0 type bypass > flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32 > dstid uf...@example.com type use > flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid > gatewayip/32 dstid uf...@example.com type require you intended that to be an ipsec.conf setup? Then I should emphasize that 87.186.99.179 is a dynamically assigned IP number... > the kernel also accepts requests to delete important system files, > change routing table entries, shutdown the machine... Ok, this sounds very much plausible. On towards isakmpd, then... > It's the phase 2 setup that you're concerned about here, and that uses > IPv4 IDs so you should be able to do this.. However isakmpd.policy *is* > complicated and hard to get right and the current ipsecctl interface > to isakmpd only deals with flows and not keynote policy. I should reiterate (unless I missed to point it out in the first place) that my configuration, the offending part of it being included below, was running fine for several years and only broke down with the advent of a new client software package. Also, I'm confident that I'm not using IPv4 numbers as IDs. See this, replicated from the test server that I set up: Authorizer: "mobile-certs" Comment: need to list all certificates for mobile users in the licensees section Licensees: "DN:/Cert/Of/User1" || "DN:/Cert/Of/User2" Conditions: app_domain == "IPsec policy" && esp_present == "yes" && esp_enc_alg == "aes" && phase_1 == "main" && phase1_group_desc == "5" && esp_encapsulation == "tunnel" && esp_auth_alg == "hmac-sha" && ( esp_key_length == "256" || esp_key_length == "128" ) && remote_filter_type == "IPv4 address" && remote_filter == "192.168.003.000-192.168.003.255" && remote_filter_addr_lower == "192.168.003.000" && remote_filter_addr_upper == "192.168.003.255" && pfs == "yes" && remote_id_type == "User FQDN" && ( remote_id == "us...@example.com" || remote_id == "us...@example.com" ) -> "true"; The logs show very interesting things here: For the working correction, isakmpd logs this: ... @40004bc4583501a93d54 134027.027819 Plcy 80 remote_filter_type == IPv4 address @40004bc4583501a94cf4 134027.027844 Plcy 80 remote_filter_addr_upper == 192.168.003.151 @40004bc4583501a958ac 134027.027849 Plcy 80 remote_filter_addr_lower == 192.168.003.151 @40004bc4583501aa1bfc 134027.027861 Plcy 80 remote_filter == 192.168.003.151 ... The IP address, 192.168.003.151, is assigned using IKECFG. Please note that the filter statements don't reflect the configuration. For the broken connection with that same client, as far as my configuration is concerned, isakmpd logs this: ... @40004bc46e072af0745c 151333.720391 Plcy 80 remote_filter_type == IPv4 subnet @40004bc46e072af08fb4 151333.720394 Plcy 80 remote_filter_addr_upper == 255.255.255.255 @40004bc46e072af09b6c 151333.720398 Plcy 80 remote_filter_addr_lower == 000.000.000.000 @40004bc46e072af0a33c 151333.720402 Plcy 80 remote_filter == 000.000.000.000-255.255.255.255 ... I'd say that one can at least conclude that the filter does not apply because I can only specify one filter type, and suddenly, I'm looking at a (broken) proposal of a different type. I should also add that I'm still unable to use ipsec.conf, as I'm using more features of IPSEC than I can express with ipsec.conf... so it's old-style isakmpd.conf + isakmpd.policy over here. [OT: It would be signed keynote credentials once I'd figure out the format.] FWIW, the vendor of the package says that he only changed the Vendor-ID between the two software versions, but in any case, it would now be time to have _two_ (or more) different filters, instead of only one, which is all I can see possible in isakmpd.policy(5). -- Kind regards, --Toni++
Re: isakmpd & policy questions
Hi, On Tue, 13.04.2010 at 17:42:52 +0200, Toni Mueller wrote: > Authorizer: "mobile-certs" > Comment: need to list all certificates for mobile users in the licensees > section > Licensees: "DN:/Cert/Of/User1" || > "DN:/Cert/Of/User2" > Conditions: app_domain == "IPsec policy" > && esp_present == "yes" > && esp_enc_alg == "aes" > && phase_1 == "main" > && phase1_group_desc == "5" > && esp_encapsulation == "tunnel" > && esp_auth_alg == "hmac-sha" > && ( esp_key_length == "256" || esp_key_length == "128" ) > && remote_filter_type == "IPv4 address" > && remote_filter == "192.168.003.000-192.168.003.255" > && remote_filter_addr_lower == "192.168.003.000" > && remote_filter_addr_upper == "192.168.003.255" > && pfs == "yes" > && remote_id_type == "User FQDN" > && ( remote_id == "us...@example.com" || remote_id == > "us...@example.com" ) -> "true"; I've now made sure to retry with "IPv4 subnet" instead of "IPv4 address", but with exactly the same result. Isakmpd logs the following, which I have to find out whether this is generated somewhere within isakmpd, or sent by the client: ... @40004bc5aacc2ce2c2c4 134506.752860 Plcy 80 remote_filter_type == IPv4 subnet @40004bc5aacc2ce2da34 134506.752864 Plcy 80 remote_filter_addr_upper == 255.255.255.255 @40004bc5aacc2ce30cfc 134506.752870 Plcy 80 remote_filter_addr_lower == 000.000.000.000 @40004bc5aacc2ce3340c 134506.752882 Plcy 80 remote_filter == 000.000.000.000-255.255.255.255 @40004bc5aacc2ce343ac 134506.752888 Plcy 80 remote_filter_port == 0 @40004bc5aacc2ce37a5c 134506.752894 Plcy 80 remote_filter_proto == 0 @40004bc5aacc2ce3ad24 134506.752904 Plcy 80 local_filter_type == IPv4 subnet @40004bc5aacc2ce3cc64 134506.752914 Plcy 80 local_filter_addr_upper == 255.255.255.255 @40004bc5aacc2ce3eba4 134506.752921 Plcy 80 local_filter_addr_lower == 000.000.000.000 @40004bc5aacc2ce3fb44 134506.752933 Plcy 80 local_filter == 000.000.000.000-255.255.255.255 @40004bc5aacc2ce40ecc 134506.752942 Plcy 80 local_filter_port == 0 @40004bc5aacc2ce44d4c 134506.752949 Plcy 80 local_filter_proto == 0 @40004bc5aacc2ce4745c 134506.752972 Plcy 80 remote_id_type == User FQDN @40004bc5aacc2ce48bcc 134506.752980 Plcy 80 remote_id_addr_upper == @40004bc5aacc2ce4c664 134506.752989 Plcy 80 remote_id_addr_lower == @40004bc5aacc2ce4d9ec 134506.752995 Plcy 80 remote_id == us...@example.com @40004bc5aacc2ce51484 134506.753003 Plcy 80 remote_id_port == 0 @40004bc5aacc2ce53f7c 134506.753022 Plcy 80 remote_id_proto == 0 @40004bc5aacc2ce54f1c 134506.753028 Plcy 80 remote_negotiation_address == 088.128.046.032 @40004bc5aacc2ce5c44c 134506.753038 Plcy 80 local_negotiation_address == 193.221.127.062 @40004bc5aacc2ce5d3ec 134506.753044 Plcy 80 pfs == yes @40004bc5aacc2ce6397c 134506.753053 Plcy 80 initiator == no @40004bc5aacc2ce66474 134506.753057 Plcy 80 phase1_group_desc == 5 @40004bc5aacc2ce677fc 134506.753155 Plcy 40 check_policy: kn_do_query returned 1 Stay tuned for another hack... :/ -- Kind regards, --Toni++
Re: [patch] Re: hacking pfkey: a few questions
On Wed, 14.04.2010 at 16:14:32 +0200, Markus Friedl wrote: > yes, just writing an appropriate isakmpd.policy file should work:: > > Authorizer: "POLICY" > Conditions: app_domain == "IPsec policy" && > ( remote_filter != "000.000.000.000-255.255.255.255" ) -> "true"; I had configured this and just got feedback that this did not work. Kind regards, --Toni++
problem understanding install.md and the shell in general
Hi,
while playing with Nick Bender's auto-install stuff, I hit a problem:
In src/distrib/i386/common/install.md, I see this code:
NCPU=$(sysctl -n hw.ncpufound)
((NCPU > 1)) && { DEFAULTSETS="bsd bsd.rd bsd.mp" ; SANESETS="bsd bsd.mp" ; }
Executing this during install, or from a shell reached after booting
bsd.rd, yields:
/install.auto: //install.md[6]: NCPU: not found
I've copied the two lines above into an isolated shell script and ran
that shell script, with exactly the same result. Then I carried this
two-liner over to a machine which was already running full multi-user,
and now, the script worked just fine. But the code can't be broken,
otherwise installs would not work properly, so I guess I'm doing
something wrong.
If I use the following code instead, no problem occurs:
[ NCPU -gt 1 ] && ...
I read the man page for the shell several times, but didn't figure out
where this behaviour is described:
(( expression )) -- I only found $(( expression ))
PARAMETER -- I only found $PARAMETER
What gives?
Since I'm in a hurry to fix this problem, I also took a closer look and
fixed the problem for me. The value of NCPU is only used to decide
whether to install the MP kernel as /bsd. Since there is nowhere any
logic to decide whether there is enough disk space to hold all three
kernel files, this can be simplified while saving a few bytes at the
same time:
--- /tmp/install.md 2009-06-11 19:05:06.0 +0200
+++ install.md 2010-04-27 23:46:58.0 +0200
@@ -34,13 +34,13 @@
MDXAPERTURE=2
MDXDM=y
-NCPU=$(sysctl -n hw.ncpufound)
-((NCPU > 1)) && { DEFAULTSETS="bsd bsd.rd bsd.mp" ; SANESETS="bsd bsd.mp" ; }
+DEFAULTSETS="bsd bsd.rd bsd.mp"
+SANESETS="bsd bsd.mp"
md_installboot() {
cd /mnt
- if [[ -f bsd.mp ]] && ((NCPU > 1)); then
+ if [[ -f bsd.mp ]] && [$(sysctl -n hw.ncpufound) -gt 1 ]; then
echo "Multiprocessor machine; using bsd.mp instead of bsd."
mv bsd bsd.sp 2>/dev/null
mv bsd.mp bsd
Enjoy,
--Toni++
Re: problem understanding install.md and the shell in general [SOLVED]
Hi, thanks to all who pointed out that this was a classical PEBKAC. :| And sorry for the noise. -- Kind regards, --Toni++
+ papers?
Hi, imho, the 'papers' collection has valuable information, and users are often enough referred to them for a better understanding about where the project is headed. But they are not very visible. The following patch is intended to give them better visibility: --- index.html.orig 2010-03-14 00:31:04.0 +0100 +++ index.html 2010-04-29 16:46:46.0 +0200 @@ -60,6 +60,7 @@ Mailing Lists Application Packages Books that Help + Papers http://undeadly.org/";>OpenBSD Journal Supporting OpenBSD Kind regards, --Toni++
