Re: I unveil()ed ftp(1)!
there was tiny error I created.
-Luke
On Wed, Jun 3, 2020 at 2:24 PM Luke Small wrote:
> There! It doesn't use an unveil list. It has 2 dry runs as proposed.
> It could just have a dry run to see if it goes into interactive mode
> and then unveil as we go! but I like to see all the unveil calls before
> the ftp output statements myself!
> -Luke
>
>
> On Wed, Jun 3, 2020 at 11:30 AM Luke Small wrote:
>
>> Or you could have 2 dry runs. One to merely see that it won't head into
>> interactive mode
>> and a second one to start the unveiling directly in fetch.c. Unless
>> unveil itself will
>> have too many entries!
>> -Luke
>>
>>
>> On Wed, Jun 3, 2020 at 11:12 AM Luke Small wrote:
>>
>>> I figure if it took up that much stack space from before, it'd start
>>> needing to
>>> dang near run the stack into on-disk virtual memory anyway. At that
>>> point,
>>> it'd perhaps be a better design choice to break up your ftp calls into
>>> slightly
>>> smaller chunks to avoid massively poor performance, yeah? LOL
>>>
>>> If you're really worried about it, perhaps you could put in a goto which
>>> jumps
>>> over the offending part, when argc is so massive that
>>> it would cause such a thing...Hmmm.
>>> -Luke
>>>
>>>
>>> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt
>>> wrote:
>>>
You really don't get it.
+ unveil_list = calloc(2 * argc, sizeof(char*));
Imagine argc is 1.
+ for (i = 2 * argc - 2; i >= 0; i -= 2) {
+ if (unveil_list[i]) {
+ if (unveil(unveil_list[i], "r")
== -1)
...
+ if (unveil_list[i | 1]) {
+ if (unveil(unveil_list[i | 1],
"cw") == -1)
+ err(1, "unveil");
...
E2BIG The addition of path would exceed the
per-process
limit for unveiled paths.
Great, under fairly normal usage ftp aborts with an error.
Since you start with up to 8 others, it looks like this limit is easily
hit at around 120 filenames.
So ftp simply fails to perform the task it is designed for.
Your proposal is to break the command.
Common subdirectories: /usr/src/usr.bin/ftp/CVS and /home/luke/ftp/CVS
diff -uNp /usr/src/usr.bin/ftp/extern.h /home/luke/ftp/extern.h
--- /usr/src/usr.bin/ftp/extern.h Thu May 16 07:44:17 2019
+++ /home/luke/ftp/extern.h Wed Jun 3 13:41:49 2020
@@ -69,6 +69,7 @@ void abortrecv(int);
void alarmtimer(int);
int another(int *, char ***, const char *);
int auto_fetch(int, char **, char *);
+int auto_fetch_u(int, char **, char *, int, int);
void blkfree(char **);
void cdup(int, char **);
void cmdabort(int);
diff -uNp /usr/src/usr.bin/ftp/fetch.c /home/luke/ftp/fetch.c
--- /usr/src/usr.bin/ftp/fetch.c Fri Feb 21 19:00:07 2020
+++ /home/luke/ftp/fetch.c Wed Jun 3 15:51:45 2020
@@ -68,8 +68,10 @@ struct tls;
#include "ftp_var.h"
#include "cmds.h"
-static int file_get(const char *, const char *);
+//~ static int file_get(const char *, const char *);
+static int file_get_u(const char *, const char *, int, int);
static int url_get(const char *, const char *, const char *, int);
+static int url_get_u(const char *, const char *, const char *, int, int, int);
static int save_chunked(FILE *, struct tls *, int , char *, size_t);
static void aborthttp(int);
static void abortfile(int);
@@ -186,8 +188,14 @@ tooslow(int signo)
* Copy a local file (used by the OpenBSD installer).
* Returns -1 on failure, 0 on success
*/
+//~ static int
+//~ file_get(const char *path, const char *outfile)
+//~ {
+ //~ return file_get_u(path, outfile, 1, 0);
+//~ }
+
static int
-file_get(const char *path, const char *outfile)
+file_get_u(const char *path, const char *outfile, int ready, int tout)
{
struct stat st;
int fd, out, rval = -1, save_errno;
@@ -200,17 +208,28 @@ file_get(const char *path, const char *outfile)
direction = "received";
- fd = open(path, O_RDONLY);
- if (fd == -1) {
- warn("Can't open file %s", path);
- return -1;
- }
+ if (ready) {
+
+ fd = open(path, O_RDONLY);
+ if (fd == -1) {
+ warn("Can't open file %s", path);
+ return -1;
+ }
- if (fstat(fd, ) == -1)
- filesize = -1;
- else
- filesize = st.st_size;
+ if (fstat(fd, ) == -1)
+ filesize = -1;
+ else
+ filesize = st.st_size;
+ } else {
+ if (unveil(path, "r") == -1)
+ err(1, "unveil");
+ dprintf(tout, "unveil(%s, \"r\")\n", path);
+ if (pipeout)
+ return 0;
+ }
+
+
if (outfile != NULL)
savefile = outfile;
else {
@@ -220,6 +239,14 @@ file_get(const char *path, const char *outfile)
savefile = basename(path);
}
+ if (!ready) {
+ if (unveil(savefile, "cw") == -1)
+ err(1, "unveil");
+
+ dprintf(tout, "unveil(%s, \"cw\")\n", savefile);
+ return 0;
+ }
+
if
Re: I unveil()ed ftp(1)!
There! It doesn't use an unveil list. It has 2 dry runs as proposed.
It could just have a dry run to see if it goes into interactive mode
and then unveil as we go! but I like to see all the unveil calls before
the ftp output statements myself!
-Luke
On Wed, Jun 3, 2020 at 11:30 AM Luke Small wrote:
> Or you could have 2 dry runs. One to merely see that it won't head into
> interactive mode
> and a second one to start the unveiling directly in fetch.c. Unless unveil
> itself will
> have too many entries!
> -Luke
>
>
> On Wed, Jun 3, 2020 at 11:12 AM Luke Small wrote:
>
>> I figure if it took up that much stack space from before, it'd start
>> needing to
>> dang near run the stack into on-disk virtual memory anyway. At that point,
>> it'd perhaps be a better design choice to break up your ftp calls into
>> slightly
>> smaller chunks to avoid massively poor performance, yeah? LOL
>>
>> If you're really worried about it, perhaps you could put in a goto which
>> jumps
>> over the offending part, when argc is so massive that
>> it would cause such a thing...Hmmm.
>> -Luke
>>
>>
>> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt
>> wrote:
>>
>>> You really don't get it.
>>>
>>> + unveil_list = calloc(2 * argc, sizeof(char*));
>>>
>>> Imagine argc is 1.
>>>
>>> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
>>> + if (unveil_list[i]) {
>>> + if (unveil(unveil_list[i], "r")
>>> == -1)
>>> ...
>>> + if (unveil_list[i | 1]) {
>>> + if (unveil(unveil_list[i | 1],
>>> "cw") == -1)
>>> + err(1, "unveil");
>>> ...
>>>
>>>
>>> E2BIG The addition of path would exceed the per-process
>>> limit for unveiled paths.
>>>
>>>
>>> Great, under fairly normal usage ftp aborts with an error.
>>>
>>> Since you start with up to 8 others, it looks like this limit is easily
>>> hit at around 120 filenames.
>>>
>>> So ftp simply fails to perform the task it is designed for.
>>>
>>> Your proposal is to break the command.
>>>
>>>
/* $OpenBSD: fetch.c,v 1.194 2020/02/22 01:00:07 jca Exp $ */
/* $NetBSD: fetch.c,v 1.14 1997/08/18 10:20:20 lukem Exp $ */
/*-
* Copyright (c) 1997 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Jason Thorpe and Luke Mewburn.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
/*
* FTP User Program -- Command line file retrieval
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef NOSSL
#include
#else /* !NOSSL */
struct tls;
#endif /* !NOSSL */
#include "ftp_var.h"
#include "cmds.h"
//~ static int file_get(const char *, const char *);
static int file_get_u(const char *, const char *, int, int);
static int url_get(const char *, const char *, const char *, int);
static int url_get_u(const char *, const char *, const char *, int, int, int);
static int save_chunked(FILE *, struct tls *, int , char *, size_t);
static void aborthttp(int);
static void abortfile(int);
static char hextochar(const char *);
static char *urldecode(const char *);
static char *recode_credentials(const char *_userinfo);
static char *ftp_readline(FILE *, size_t *);
static void ftp_close(FILE **, struct tls **, int *);
static const char *sockerror(struct tls *);
#ifdef SMALL
#define ftp_printf(fp, ...) fprintf(fp, __VA_ARGS__)
#else
static int ftp_printf(FILE *, const char *,
Re: Offline autoinstall(install.conf)
On Tue, Jun 02, 2020 at 01:48:33PM +, RT wrote: > I have already gone through the autoinstall man page but I didn't understand > how to do that using local(offline without the TFTP server) file(do I need to > write rewrite the bsd.rd and include the install.conf file? from > https://marc.info/?l=openbsd-misc=141552533922277=2) As the ramdisk is embedded in bsd.rd, if you want to do a local autoinstall you need to create a bsd.rd file that contains a ramdisk with your install.conf in there, under the name /auto_install.conf (as described in autoinstall(8)). The link you gave describes a good method of doing that, and nowadays it's easier because rdsetroot is part of the base system so you don't even need to build it. Regards, Jurjen Oskam
Re: Privoxy crashes on one OpenBSD machine but not another
TJ wrote:
> I'm migrating my system configs from one OpenBSD machine (Pentium 4) to
> another (Core 2 Duo).
>
> I noticed unpredictable crashes of the Privoxy package when run and used
> on the C2D computer. These crashes don't occur on the P4 at all, with
> the same traffic.
I tried to reproduce the crashes with OpenBSD 6.7 amd64
and Privoxy 3.0.29 built from git and Privoxy reliably
crashes when executing a regression test ...
The crash I encountered seems to be triggered by long
host names resolved from a thread.
Here's a reduced test case:
openbsd$ cat resolve.c
#include
#include
#include
#include
#include
#include
pthread_mutex_t mutex;
void resolve(char *host) {
int error;
error = pthread_mutex_lock();
if (error) {
printf("Locking failed: %s", strerror(error));
exit(1);
}
printf("Calling gethostbyname with %s\n", host);
gethostbyname(host);
pthread_mutex_unlock();
}
int main(int argc, char **argv) {
pthread_t the_thread;
pthread_attr_t attrs;
int i;
if (!argc) {
printf("No argument to resolve given\n");
exit(1);
}
pthread_attr_init();
pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
pthread_mutex_init(, NULL);
for (i = 0; i < 3; i++) {
pthread_create(_thread, , (void * (*)(void *))resolve,
argv[1]);
}
sleep(1);
exit(0);
}
openbsd$ clang -pthread -ggdb -Wall -o resolve resolve.c
openbsd$ ./resolve
AAA.example.org
Calling gethostbyname with
AAA.example.org
Calling gethostbyname with
AAA.example.org
Calling gethostbyname with
AAA.example.org
openbsd$ ./resolve
.example.org
Calling gethostbyname with
.example.org
Segmentation fault (core dumped)
openbsd$ egdb resolve resolve.core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.7".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Re: issue with IKEv2 setup
On Wed, Jun 03, 2020 at 02:07:52PM -0400, Sonic wrote: > On Wed, Jun 3, 2020 at 1:49 PM Tobias Heider wrote: > > It does. /etc/iked/pubkeys/fqdn/server2.domain is where the peer's public > > key > > should be. > > The peers public key is there, the peer, as far as I can tell is > server1.domain, yet the example shows server2.domain. > Ah true, there seems to be a typo in the faq. Try setting dstid to 'server1.domain'.
Re: issue with IKEv2 setup
On Wed, Jun 3, 2020 at 1:49 PM Tobias Heider wrote: > It does. /etc/iked/pubkeys/fqdn/server2.domain is where the peer's public key > should be. The peers public key is there, the peer, as far as I can tell is server1.domain, yet the example shows server2.domain.
Re: issue with IKEv2 setup
On Wed, Jun 03, 2020 at 01:09:02PM -0400, Sonic wrote:
> Following the FAQ at https://www.openbsd.org/faq/faq17.html I ran into
> the following problem with the server2 example:
> ===
> ikev2 'server2_rsa' active esp \
> from 10.0.2.0/24 to 10.0.1.0/24 \
> peer 192.0.2.1 \
> dstid server2.domain
> ===
>
> ===
> # iked -dv
> set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/server2.domain
> ===
>
> Is the above an error to be concerned with? Doesn't the system know
> that its pubkey exists as /etc/iked/local.pub ?
It does. /etc/iked/pubkeys/fqdn/server2.domain is where the peer's public key
should be.
>
> Should /etc/iked/local.pub be copied to /etc/iked/pubkeys/fqdn/server2.domain
> ?
>
> (of course I'm using the actual fqdn of the systems in question and
> literally serverX.domaIn)
>
> No such error on the server1 example, although it seems that srcid is
> not checked for the pubkey as dstid is.
>
> Chris
>
>From https://www.openbsd.org/faq/faq17.html:
Building Site-to-site VPNs
This can be achieved by exchanging the default-provided RSA public keys:
/etc/iked/local.pub on the first system ("server1") should be copied to
/etc/iked/pubkeys/fqdn/server1.domain on the second system ("server2").
Then, /etc/iked/local.pub on the second system should be copied to
/etc/iked/pubkeys/fqdn/server2.domain on the first.
Replace "serverX.domain" with your own FQDN.
issue with IKEv2 setup
Following the FAQ at https://www.openbsd.org/faq/faq17.html I ran into the following problem with the server2 example: === ikev2 'server2_rsa' active esp \ from 10.0.2.0/24 to 10.0.1.0/24 \ peer 192.0.2.1 \ dstid server2.domain === === # iked -dv set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/server2.domain === Is the above an error to be concerned with? Doesn't the system know that its pubkey exists as /etc/iked/local.pub ? Should /etc/iked/local.pub be copied to /etc/iked/pubkeys/fqdn/server2.domain ? (of course I'm using the actual fqdn of the systems in question and literally serverX.domaIn) No such error on the server1 example, although it seems that srcid is not checked for the pubkey as dstid is. Chris
Re: I unveil()ed ftp(1)!
Or you could have 2 dry runs. One to merely see that it won't head into
interactive mode
and a second one to start the unveiling directly in fetch.c. Unless unveil
itself will
have too many entries!
-Luke
On Wed, Jun 3, 2020 at 11:12 AM Luke Small wrote:
> I figure if it took up that much stack space from before, it'd start
> needing to
> dang near run the stack into on-disk virtual memory anyway. At that point,
> it'd perhaps be a better design choice to break up your ftp calls into
> slightly
> smaller chunks to avoid massively poor performance, yeah? LOL
>
> If you're really worried about it, perhaps you could put in a goto which
> jumps
> over the offending part, when argc is so massive that
> it would cause such a thing...Hmmm.
> -Luke
>
>
> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt wrote:
>
>> You really don't get it.
>>
>> + unveil_list = calloc(2 * argc, sizeof(char*));
>>
>> Imagine argc is 1.
>>
>> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
>> + if (unveil_list[i]) {
>> + if (unveil(unveil_list[i], "r")
>> == -1)
>> ...
>> + if (unveil_list[i | 1]) {
>> + if (unveil(unveil_list[i | 1],
>> "cw") == -1)
>> + err(1, "unveil");
>> ...
>>
>>
>> E2BIG The addition of path would exceed the per-process
>> limit for unveiled paths.
>>
>>
>> Great, under fairly normal usage ftp aborts with an error.
>>
>> Since you start with up to 8 others, it looks like this limit is easily
>> hit at around 120 filenames.
>>
>> So ftp simply fails to perform the task it is designed for.
>>
>> Your proposal is to break the command.
>>
>>
Re: I unveil()ed ftp(1)!
I figure if it took up that much stack space from before, it'd start
needing to
dang near run the stack into on-disk virtual memory anyway. At that point,
it'd perhaps be a better design choice to break up your ftp calls into
slightly
smaller chunks to avoid massively poor performance, yeah? LOL
If you're really worried about it, perhaps you could put in a goto which
jumps
over the offending part, when argc is so massive that
it would cause such a thing...Hmmm.
-Luke
On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt wrote:
> You really don't get it.
>
> + unveil_list = calloc(2 * argc, sizeof(char*));
>
> Imagine argc is 1.
>
> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
> + if (unveil_list[i]) {
> + if (unveil(unveil_list[i], "r") ==
> -1)
> ...
> + if (unveil_list[i | 1]) {
> + if (unveil(unveil_list[i | 1],
> "cw") == -1)
> + err(1, "unveil");
> ...
>
>
> E2BIG The addition of path would exceed the per-process
> limit for unveiled paths.
>
>
> Great, under fairly normal usage ftp aborts with an error.
>
> Since you start with up to 8 others, it looks like this limit is easily
> hit at around 120 filenames.
>
> So ftp simply fails to perform the task it is designed for.
>
> Your proposal is to break the command.
>
>
Re: Mounting encrypted drive on boot
On Wed, Jun 03, 2020 at 12:27:00AM +0100, Chris Narkiewicz wrote:
[...]
> My setup consist of OpenBSD 6.7 with full drive encryption using
> softraid, configured as described in FAQ:
>
> /dev/sd0a - encrypted volume
> /dev/sd1 - decrypted
>
> I have additional need to mount an encrypted /var volume on boot.
> This volume is separate drive attached to be VPS "machine".
>
> I want to mount this drive automatically on boot by adding
> relevant entries to /etc/fstab, but before this can be done,
> softraid device must be configured using bioctl.
>
[...]
>
> Somebody on StackOverflow advised on modifying /etc/rc
> and run bioctl before disks are mounted, but I'm not sure
> if this is a right approach, especially that attaching
> more disks might change the /dev/sd* numberign.
Don't modify /etc/rc itself.
rc(8): "Normally, rc.local contains commands and daemons that are not
part of the stock installation."
I don't fully understand your question, but I used to have an rc.local
to allow using /home from an encrypted USB drive that got loaded from
rc.local. I'm not endorsing this as a great solution, but maybe this
will serve as inspiration for you to come up with your own method.
/etc/rc.local (REPLACE with your disk's DUID):
# CRYPTO_DEV assumes that home is on the k partition of a disk with the DUID
.
CRYPTO_DEV=`sysctl hw.disknames | sed -n -E "s/.*(sd[0-9]{1,2}):.*/\1/p"`
fsck -y /dev/r${CRYPTO_DEV}k
mount -o softdep,nodev,nosuid .k /home
signature.asc
Description: PGP signature
Re: I unveil()ed ftp(1)!
You really don't get it.
+ unveil_list = calloc(2 * argc, sizeof(char*));
Imagine argc is 1.
+ for (i = 2 * argc - 2; i >= 0; i -= 2) {
+ if (unveil_list[i]) {
+ if (unveil(unveil_list[i], "r") == -1)
...
+ if (unveil_list[i | 1]) {
+ if (unveil(unveil_list[i | 1], "cw") ==
-1)
+ err(1, "unveil");
...
E2BIG The addition of path would exceed the per-process
limit for unveiled paths.
Great, under fairly normal usage ftp aborts with an error.
Since you start with up to 8 others, it looks like this limit is easily
hit at around 120 filenames.
So ftp simply fails to perform the task it is designed for.
Your proposal is to break the command.
Re: I unveil()ed ftp(1)!
I’ll be the first to admit that I don’t completely understand the power that is the ftp client. but what I do understand of it, from the perspective of noninteractive commandline execution, it seems to fit the bill. For file and http(s) transfers. I didn’t see any buffer overflows and I’m sure that my solution would’ve thrown some segfaults if it had overrun a buffer in my testing. All the comments like how I needed to resolve soft links of cafile have been dealt with, but I’m not shy about putting in single letter variables to perform nested looping. But it seems that the task that said couldn’t be done, was done. It adds complexity that I’m sure you aren’t comfortable with; especially since your name is on the file as the last author, but you can’t say I’m not that demandy lazy ass that didn’t do anything about it now. On Wed, Jun 3, 2020 at 9:50 AM Theo de Raadt wrote: > I mean it is amusing, because this is never going to fly. > > This increase in complexity is completely unacceptable, what I see is > completely amateurish, and I also see overflows, a lack of testing > for edge conditions, and a lack of attention to how unveil works. > > > Luke Small wrote: > > > You're welcome! I figured you might not want a “massive” diff to cap off > your day to > > make a program that you apparently feel is secure enough, but I made > good that I got > > off my ass and did something anyway. I’m surprised that you even went to > the trouble of > > pledging it myself. It only took 2 or 3 days to figure out what it was > doing and change > > it. I left in the fprintf()s to so that I could amuse you. > > > > I’m kinda surprised that you didn’t go straight for the “submit a diff. > Anything you > > submit will just be rejected anyway!” > > > > On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt > wrote: > > > > Thank you for the laugh. > > > > Luke Small wrote: > > > > > I think I'm done tinkering. try these out in ftp folder. I left in > some > > > fprintf(ttyout,...) in main.c > > > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > > > and SSL_PATH variables. > > > It leaves in place the functionality of the original functions, but > adds > > > the availability to perform > > > a dry run pass to load an unveil list of potential files from which > to read > > > and create/write. > > > The only potential bug is perhaps if in the followup unveiled pass if > it > > > has a problem with dns resolution or > > > something, it may be unveiled and drop into a command line. I'm not > sure. > > > > > > The diff is of the three files below vs the originals since I last > updated > > > the source files. > > > > > > -Luke > > > -- > > > -Luke > > > > -- > > -Luke > > > -- -Luke
Re: I unveil()ed ftp(1)!
I mean it is amusing, because this is never going to fly. This increase in complexity is completely unacceptable, what I see is completely amateurish, and I also see overflows, a lack of testing for edge conditions, and a lack of attention to how unveil works. Luke Small wrote: > You're welcome! I figured you might not want a “massive” diff to cap off your > day to > make a program that you apparently feel is secure enough, but I made good > that I got > off my ass and did something anyway. I’m surprised that you even went to the > trouble of > pledging it myself. It only took 2 or 3 days to figure out what it was doing > and change > it. I left in the fprintf()s to so that I could amuse you. > > I’m kinda surprised that you didn’t go straight for the “submit a diff. > Anything you > submit will just be rejected anyway!” > > On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt wrote: > > Thank you for the laugh. > > Luke Small wrote: > > > I think I'm done tinkering. try these out in ftp folder. I left in some > > fprintf(ttyout,...) in main.c > > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > > and SSL_PATH variables. > > It leaves in place the functionality of the original functions, but adds > > the availability to perform > > a dry run pass to load an unveil list of potential files from which to read > > and create/write. > > The only potential bug is perhaps if in the followup unveiled pass if it > > has a problem with dns resolution or > > something, it may be unveiled and drop into a command line. I'm not sure. > > > > The diff is of the three files below vs the originals since I last updated > > the source files. > > > > -Luke > > -- > > -Luke > > -- > -Luke >
Re: I unveil()ed ftp(1)!
You're welcome! I figured you might not want a “massive” diff to cap off your day to make a program that you apparently feel is secure enough, but I made good that I got off my ass and did something anyway. I’m surprised that you even went to the trouble of pledging it myself. It only took 2 or 3 days to figure out what it was doing and change it. I left in the fprintf()s to so that I could amuse you. I’m kinda surprised that you didn’t go straight for the “submit a diff. Anything you submit will just be rejected anyway!” On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt wrote: > Thank you for the laugh. > > > Luke Small wrote: > > > I think I'm done tinkering. try these out in ftp folder. I left in some > > fprintf(ttyout,...) in main.c > > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > > and SSL_PATH variables. > > It leaves in place the functionality of the original functions, but adds > > the availability to perform > > a dry run pass to load an unveil list of potential files from which to > read > > and create/write. > > The only potential bug is perhaps if in the followup unveiled pass if it > > has a problem with dns resolution or > > something, it may be unveiled and drop into a command line. I'm not sure. > > > > The diff is of the three files below vs the originals since I last > updated > > the source files. > > > > -Luke > > -- > > -Luke > -- -Luke
Re: I unveil()ed ftp(1)!
Thank you for the laugh. Luke Small wrote: > I think I'm done tinkering. try these out in ftp folder. I left in some > fprintf(ttyout,...) in main.c > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > and SSL_PATH variables. > It leaves in place the functionality of the original functions, but adds > the availability to perform > a dry run pass to load an unveil list of potential files from which to read > and create/write. > The only potential bug is perhaps if in the followup unveiled pass if it > has a problem with dns resolution or > something, it may be unveiled and drop into a command line. I'm not sure. > > The diff is of the three files below vs the originals since I last updated > the source files. > > -Luke > -- > -Luke
I unveil()ed ftp(1)!
I think I'm done tinkering. try these out in ftp folder. I left in some
fprintf(ttyout,...) in main.c
to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
and SSL_PATH variables.
It leaves in place the functionality of the original functions, but adds
the availability to perform
a dry run pass to load an unveil list of potential files from which to read
and create/write.
The only potential bug is perhaps if in the followup unveiled pass if it
has a problem with dns resolution or
something, it may be unveiled and drop into a command line. I'm not sure.
The diff is of the three files below vs the originals since I last updated
the source files.
-Luke
--
-Luke
diff
Description: Binary data
/* $OpenBSD: main.c,v 1.131 2020/02/11 18:41:39 deraadt Exp $ */
/* $NetBSD: main.c,v 1.24 1997/08/18 10:20:26 lukem Exp $ */
/*
* Copyright (C) 1997 and 1998 WIDE Project.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. Neither the name of the project nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* Copyright (c) 1985, 1989, 1993, 1994
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* FTP User Program -- Command Interface.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "cmds.h"
#include "ftp_var.h"
#ifndef SMALL
#include "pathnames.h"
#endif
int connect_timeout;
#ifndef NOSSL
char * const ssl_verify_opts[] = {
#define SSL_CAFILE 0
"cafile",
#define SSL_CAPATH 1
"capath",
#define SSL_CIPHERS 2
"ciphers",
#define SSL_DONTVERIFY 3
"dont",
#define SSL_DOVERIFY 4
"do",
#define SSL_VERIFYDEPTH 5
"depth",
#define SSL_MUSTSTAPLE 6
"muststaple",
#define SSL_NOVERIFYTIME 7
"noverifytime",
#define SSL_SESSION 8
"session",
NULL
};
struct tls_config *tls_config;
int tls_session_fd = -1;
static void
process_ssl_options(char *cp, char *ca_file, char *ca_path)
{
const char *errstr;
long long depth;
char *str;
while (*cp) {
switch (getsubopt(, ssl_verify_opts, )) {
case SSL_CAFILE:
if (str == NULL)
errx(1, "missing CA file");
Re: Mounting encrypted drive on boot
On 2020-06-02 23:27, Chris Narkiewicz wrote: > Somebody on StackOverflow advised on modifying /etc/rc > and run bioctl before disks are mounted, but I'm not sure > if this is a right approach, especially that attaching > more disks might change the /dev/sd* numberign. That would cause yourself maintenance pain/broken systems. A less broken solution, would be more targeted. I have retrofitted encryption before, to allow manual post boot activation of encryption via ssh, when abroad, without leaving a fob. Mounting a mail drive and also encrypted /var/spool and a backup drive from /etc/rc.securelevel. When it asks for a password on boot, rc.securelvel runs fsck -p ... && /sbin/mount ... (... = duid etc) It also reads the passwords for the extra volumes with bioctl -p, for convenience of only entering one password. Obviously the passwords are readable only by root and stored on the first encrypted drive.
Re: Could somebody please put unveil() in ftp(1)?
I think I'm done tinkering. try these out in ftp folder. I left in some
fprintf(ttyout,...) in main.c
to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
and SSL_PATH variables.
It leaves in place the functionality of the original functions, but adds
the availability to perform
a dry run pass to load an unveil list of potential files from which to read
and create/write.
The only potential bug is perhaps if in the followup unveiled pass if it
has a problem with dns resolution or
something, it may be unveiled and drop into a command line. I'm not sure.
The diff is of the three files below vs the originals since I last updated
the source files.
-Luke
On Tue, Jun 2, 2020 at 12:43 PM Kevin Chadwick wrote:
> On 2020-06-02 17:28, Luke Small wrote:
> > I don’t have experience doing diffs. Are there flags I should be using
> in diff
> > or should I do diffs on each file? It’s just 3 files.
>
> I don't have that much experience myself, but if you look in tech@ you
> will see
> plenty of examples of cvs and git diffs for multiple files in one email
> inlined
> as text in the email itself.
>
> You may have to turn text wrapping off, etc. depending on your email
> client.
>
diff
Description: Binary data
/* $OpenBSD: main.c,v 1.131 2020/02/11 18:41:39 deraadt Exp $ */
/* $NetBSD: main.c,v 1.24 1997/08/18 10:20:26 lukem Exp $ */
/*
* Copyright (C) 1997 and 1998 WIDE Project.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. Neither the name of the project nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* Copyright (c) 1985, 1989, 1993, 1994
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* FTP User Program -- Command Interface.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "cmds.h"
#include "ftp_var.h"
#ifndef SMALL
#include "pathnames.h"
#endif
int connect_timeout;
#ifndef NOSSL
char * const ssl_verify_opts[] = {
#define SSL_CAFILE 0
"cafile",
#define SSL_CAPATH 1
"capath",
#define SSL_CIPHERS 2
"ciphers",
#define SSL_DONTVERIFY 3
