Re: OpenBSD::Tame perl wrapper for tame(2)
> Your contributions to the lists are rants or useless noise. What's your > motivation and do you really gain something by doing that? Like mentioning the ruby idiot is an idiot? Sure. Who the "contributor" are you?
Re: OpenBSD::Tame perl wrapper for tame(2)
On Jul 21, 2015 11:21 PM, wrote: > > > Wrant.. Go away. > > On my way out can I gently kick the usual ruby wrapper to death? > Several times. I'd come for more. > > > Your attitude is offensive to all of us who work on this project. > > Why is open speech offensive, we're not that old already? Your contributions to the lists are rants or useless noise. What's your motivation and do you really gain something by doing that? -- Regards, Ville
Re: OpenBSD::Tame perl wrapper for tame(2)
> Wrant.. Go away. On my way out can I gently kick the usual ruby wrapper to death? Several times. I'd come for more. > Your attitude is offensive to all of us who work on this project. Why is open speech offensive, we're not that old already?
Re: OpenBSD::Tame perl wrapper for tame(2)
Wrant.. Go away. If you had any experience as a real developer on anything you would understand the message to wait until the API is stable, otherwise we're just wasting people's time and effort. Your attitude is offensive to all of us who work on this project. Please take your ungratefulness and sense of entitlement to another project. I'm sure there are Linux distributions you would get more out of. Get off our mailing lists, or shut the fuck up. Your choice. -Bob On Tue, Jul 21, 2015 at 1:37 PM, wrote: > Is it not too early to jump gun on this, stone carving gemologist > procto international man of mystery and disguise? >
Re: OpenBSD::Tame perl wrapper for tame(2)
Is it not too early to jump gun on this, stone carving gemologist procto international man of mystery and disguise?
Re: OpenBSD::Tame perl wrapper for tame(2)
This is extremely premature. The tame() in my devtree already has major incompatible changes.
Re: doas failsafe
> Your diff doesn't apply here, can you resend? You can kiss anybody's ass. Are you traditionally ridiculing your origin or the general state of software? Idiot. Quit the crapping and do some real thinking and work actually.
OpenBSD::Tame perl wrapper for tame(2)
This allows tame(2) to be used from perl. I almost never write perl and this is my first time using perl-XS, so apologies if anything is wrong. I'm not sure how generally useful this will be currently in the base system, so this may be premature, but if we want it later this should hopefully give us a good base to start. Thanks to guenther@, most of the perl-XS specific stuff is taken from his work on OpenBSD::MkTemp. Thoughts? Thanks, Jeremy Index: gnu/usr.bin/perl/cpan/OpenBSD-Tame/README === RCS file: gnu/usr.bin/perl/cpan/OpenBSD-Tame/README diff -N gnu/usr.bin/perl/cpan/OpenBSD-Tame/README --- /dev/null 1 Jan 1970 00:00:00 - +++ gnu/usr.bin/perl/cpan/OpenBSD-Tame/README 21 Jul 2015 17:01:16 - @@ -0,0 +1,28 @@ +OpenBSD-Tame version 0.01 +=== + +A simple wrapper for the tame(2) system call for restricting +system operations. + +INSTALLATION + +To install this module type the following: + + perl Makefile.PL + make + make test + make install + +DEPENDENCIES + +None. + +COPYRIGHT AND LICENCE + +Copyright (C) 2015 by Jeremy Evans + +This library is free software; you can redistribute it and/or modify +it under the same terms as Perl itself, either Perl version 5.12.2 or, +at your option, any later version of Perl 5 you may have available. + + Index: gnu/usr.bin/perl/cpan/OpenBSD-Tame/Tame.xs === RCS file: gnu/usr.bin/perl/cpan/OpenBSD-Tame/Tame.xs diff -N gnu/usr.bin/perl/cpan/OpenBSD-Tame/Tame.xs --- /dev/null 1 Jan 1970 00:00:00 - +++ gnu/usr.bin/perl/cpan/OpenBSD-Tame/Tame.xs 21 Jul 2015 18:26:52 - @@ -0,0 +1,39 @@ +#include "EXTERN.h" +#include "perl.h" +#include "XSUB.h" + +#include + +MODULE = OpenBSD::Tame PACKAGE = OpenBSD::Tame + +# result = tame_real(0); +int +tame_real(int flags) + CODE: + RETVAL = tame(flags | TAME_MALLOC); + OUTPUT: + RETVAL + +# %fh = tame_flags_map( ) +SV * +tame_flags_map() + INIT: + HV * rh; + rh = (HV *)sv_2mortal((SV *)newHV()); + CODE: + hv_store(rh, "abort", 5, newSVnv(TAME_ABORT), 0); + hv_store(rh, "cmsg", 4, newSVnv(TAME_CMSG), 0); + hv_store(rh, "cpath", 5, newSVnv(TAME_CPATH), 0); + hv_store(rh, "dns", 3, newSVnv(TAME_DNS), 0); + hv_store(rh, "getpw", 5, newSVnv(TAME_GETPW), 0); + hv_store(rh, "inet", 4, newSVnv(TAME_INET), 0); + hv_store(rh, "ioctl", 5, newSVnv(TAME_IOCTL), 0); + hv_store(rh, "proc", 4, newSVnv(TAME_PROC), 0); + hv_store(rh, "rpath", 5, newSVnv(TAME_RPATH), 0); + hv_store(rh, "rw", 2, newSVnv(TAME_RW), 0); + hv_store(rh, "tmppath", 7, newSVnv(TAME_TMPPATH), 0); + hv_store(rh, "unix", 4, newSVnv(TAME_UNIX), 0); + hv_store(rh, "wpath", 5, newSVnv(TAME_WPATH), 0); + RETVAL = newRV((SV *)rh); + OUTPUT: + RETVAL Index: gnu/usr.bin/perl/cpan/OpenBSD-Tame/lib/OpenBSD/Tame.pm === RCS file: gnu/usr.bin/perl/cpan/OpenBSD-Tame/lib/OpenBSD/Tame.pm diff -N gnu/usr.bin/perl/cpan/OpenBSD-Tame/lib/OpenBSD/Tame.pm --- /dev/null 1 Jan 1970 00:00:00 - +++ gnu/usr.bin/perl/cpan/OpenBSD-Tame/lib/OpenBSD/Tame.pm 21 Jul 2015 17:52:39 - @@ -0,0 +1,81 @@ +package OpenBSD::Tame; + +use 5.012002; +use strict; +use warnings; + +use Exporter 'import'; +use Carp; + +our @EXPORT_OK = qw( tame ); +our @EXPORT = qw( tame ); +our $VERSION = '0.01'; + +require XSLoader; +XSLoader::load('OpenBSD::Tame', $VERSION); + +my $flags_map = tame_flags_map(); + +sub tame +{ + my $tame_flags = 0; + + foreach my $flag (@_) { +$tame_flags |= $flags_map->{$flag} || croak("invalid tame option: $flag"); + } + + tame_real($tame_flags) >= 0 || croak("attempt to raise tame permissions"); +} + +1; +__END__ +=head1 NAME + +OpenBSD::Tame - Perl access to tame() + +=head1 SYNOPSIS + + use OpenBSD::Tame; + + tame("abort", "rpath") + tame("rpath", "cpath", "wpath") + tame("dns", "unix", "inet") + + +=head1 DESCRIPTION + +This module provides access to the tame(2) system call for restricting +system operations. + +tame() must be called with arguments specifying which tame(2) options +should be allowed. The only tame(2) option allowed by default is +TAME_MALLOC, all other tame(2) options must be specified explicitly. +The available options are: abort, cmsg, dns, getpw, inet, ioctl, +proc, rpath, rw, tmppath, unix, wpath. + +=head2 EXPORT + + tame("abort", "rpath") + +=head2 Exportable functions + + tame("abort", "rpath") + +=head1 SEE ALSO + +tame(2) + +=head1 AUTHOR + +Jeremy Evans, Ejer...@openbsd.orge + +=head1 COPYRIGHT AND LICENSE + +Copyright (C) 2015 by Jeremy Evans + +This library is free software; you can redistribute it and/or modify +it
Re: doas failsafe
Your diff doesn't apply here, can you resend?
Re: doas failsafe
On Tue, Jul 21, 2015 at 5:30 PM, wrote: > so, why not type su rather than doas? I will not type doas. Do you? If doas supplies kind of sudo functionality than I would rather use it instead of su and being root all the time. So yes, I will.
Re: fontconfig-user.html location wrong in man pages
On Tue, Jul 14, 2015 at 08:01:20AM +0200, Matthieu Herrb wrote: > On Mon, Jul 13, 2015 at 07:59:00PM -0500, Chris Bennett wrote: > > After reading several man pages like fc-scan, etc. > > I found at the bottom: > > > > The fontconfig user's guide, in HTML format: > > /usr/share/doc/fontconfig/fontconfig-user.html. > > > > This is not the correct location, which is > > /usr/X11R6/share/doc/fontconfig/fontconfig-user.html > > > > OK? > > No. I prefer to avoid this kind of local changes. They are painful to > maintain with CVS. Yes, you are right about that. That path may be changed again later. > Either make that path configurable and let configure expand it, or do > some substituions in the OpenBSD makefile wrapper. I have been trying to get my head around both of these options, but so far, I haven't been able to. I knew nothing about auto* and I am still slowly picking up more knowledge about it. I have found a few sites with decent documentation about auto*, but it will take me more time to get a reasonable understanding of it. I see why ports people complain about it so much. I need to learn this if I am going to be able to contribute more. I don't like just watching others work and not adding my own useful work. I DO NOT want anyone to give me the answers to this problem or to point me to anything that already fixes the same kind of problem. I am not ready for that yet. Still working, Chris Bennett
Re: doas failsafe
so, why not type su rather than doas? I will not type doas. Do you?
Re: doas failsafe
On Tue, Jul 21, 2015 at 05:42:54PM +0300, li...@wrant.com wrote: > doas is extremely foul to type, compared to sudo or su > > stop inventing reasons not to make it right first time > I don't know why you are sending so many "foul" messages to this list. I have gotten to the point of not wanting to read any message from li...@wrant.com. This is a serious mailing list. tech@openbsd.org and ports@openbsd are for important diffs and important questions. I don't like writing messages like this. I would like you to follow one of these four options: 1. Contribute something useful. It doesn't matter if your diff fails to meet approval. 2. Ask questions that actually contribute something to moving OpenBSD forward. Developers and others less capable like myself, are trying to contribute. Neither they nor I want to waste our time with your bullshit. 3. Just read this mailing list and be quiet. No messages sent. 4. Worst or best option: Go away. I hope you choose well. Chris Bennett
Re: doas failsafe
doas is extremely foul to type, compared to sudo or su stop inventing reasons not to make it right first time > once again, please ignore this if you are emotional
Re: doas failsafe
> > Less code running with setuid root, the better. > > That is the entire point. So how is another binary helping reduce code without replacing completely the larger bubble?
Re: Missing descriptor in uvideo.h
On 20/07/15(Mon) 16:44, Martin Pieuchot wrote: > Is it because by ``wWord'' you mean uDword? Did you consider using an > union with #define? > I don't know what I could do with an union but I followed the advice. I rewrote the diff, dropped the data field and used a couple of macro to access the two last field. It involve a bit of pointer arithmetic but it work. Index: sys/dev/usb/uvideo.h === RCS file: /cvs/src/sys/dev/usb/uvideo.h,v retrieving revision 1.57 diff -u -p -r1.57 uvideo.h --- sys/dev/usb/uvideo.h9 Jul 2015 14:58:32 - 1.57 +++ sys/dev/usb/uvideo.h21 Jul 2015 13:26:42 - @@ -208,6 +208,18 @@ struct usb_video_camera_terminal_desc { uByte *bmControls; } __packed; +/* Table 3-7: VC Selector Unit Descriptor */ +struct usb_video_vc_selector_desc { + uByte bLength; + uByte bDescriptorType; + uByte bDescriptorSubType; + uByte bUnitID; + uByte bNrInPins; + uByte baSourceID[1]; +/* uByte iSelector; */ +#defineVC_GET_ISELECTOR(w) ((w).baSourceID[0] + (w).bNrInPins) +} __packed; + /* Table 3-8: VC Processing Unit Descriptor */ struct usb_video_vc_processing_desc { uByte bLength; @@ -222,7 +234,20 @@ struct usb_video_vc_processing_desc { /* uByte bmVideoStandards; */ } __packed; -/* Table 3-9: VC Extension Unit Descriptor */ +/* Table 3-9: VC Encoding Unit Descriptor */ +struct usb_video_vc_encoding_desc { + uByte bLength; + uByte bDescriptorType; + uByte bDescriptorSubtype; + uByte bUnitID; + uByte bSourceID; + uByte iEncoding; + uByte bControlSize; + uByte bmControls[3]; + uByte bmControlsRuntime[3]; +} __packed; + +/* Table 3-10: VC Extension Unit Descriptor */ struct usb_video_vc_extension_desc { uByte bLength; uByte bDescriptorType; @@ -233,7 +258,7 @@ struct usb_video_vc_extension_desc { uByte bNrInPins; } __packed; -/* Table 3-11: VC Endpoint Descriptor */ +/* Table 3-12: VC Endpoint Descriptor */ struct usb_video_vc_endpoint_desc { uByte bLength; uByte bDescriptorType; @@ -241,7 +266,7 @@ struct usb_video_vc_endpoint_desc { uWord wMaxTransferSize; } __packed; -/* Table 3-13: Interface Input Header Descriptor */ +/* Table 3-14: Interface Input Header Descriptor */ struct usb_video_input_header_desc { uByte bLength; uByte bDescriptorType; @@ -262,7 +287,39 @@ struct usb_video_input_header_desc_all { uByte *bmaControls; }; -/* Table 3-18: Color Matching Descriptor */ +/* Table 3-15: Interface Output Header Descriptor */ +struct usb_video_output_header_desc { + uByte bLength; + uByte bDescriptorType; + uByte bDescriptorSubtype; + uByte bNumFormats; + uWord wTotalLength; + uByte bEndpointAddress; + uByte bTerminalLink; + uByte bControlSize; + uByte bmaControls[1]; +} __packed; + +/* Table 3-18: Still Image Frame Descriptor */ +struct usb_video_still_image_frame_desc { + uByte bLength; + uByte bDescriptorType; + uByte bDescriptorSubtype; + uByte bEndpointAddress; + uByte bNumImageSizePatterns; + struct { + uWord wWidth; + uWord wHeight; + } __packed size[1]; +/* uByte bNumCompressionPattern; */ +#defineVC_GET_BNUMCOMPRESSION(w) \ + ( *( (uByte *)(w) + 5 + 4 * (w)->bNumImageSizePatterns ) ) +/* uByte bCompression[1]; */ +#defineVC_GET_BCOMPRESSION(w) \ + ( ( (uByte *)(w) + 6 + 4 * (w)->bNumImageSizePatterns ) ) +} __packed; + +/* Table 3-19: Color Matching Descriptor */ struct usb_video_color_matching_descr { uByte bLength; uByte bDescriptorType;
Brainy: Uninitialized Var in hppa64
Hi, I put here a bug among others: --- sys/arch/hppa64/dev/apic.c - struct evcount *cnt; struct apic_iv *aiv, *biv; void *iv; int irq = APIC_INT_IRQ(ih); int line = APIC_INT_LINE(ih); u_int32_t ent0; /* no mapping or bogus */ if (irq <= 0 || irq > 63) return (NULL); aiv = malloc(sizeof(struct apic_iv), M_DEVBUF, M_NOWAIT); if (aiv == NULL) { free(cnt, M_DEVBUF, 0); return NULL; } 'cnt' is not initialized. Found by The Brainy Code Scanner. Maxime
Re: Weak Diffie-Hellman default in nginx port
El Tue, 21 de Jul de 2015, a las 12:55:42PM +0200, Denis Fondras dijo: > On Tue, Jul 21, 2015 at 12:31:33PM +0200, lophos wrote: > > The nginx config (although disabled by default) supports weak Diffie > > Hellman cipher according to ssllabs.com test > > (Grade B). > > > > You'd better generate stronger DH-param than disable DHE. > I'm using the default config. This goes against the Secure by Default policy.
[PATCH] Do not intend cases in switch for doas(1)
Hi, Just a minor stylistic change. Cheers, Dimitris === RCS file: /cvs/src/usr.bin/doas/parse.y,v retrieving revision 1.7 diff -u -p -r1.7 parse.y --- parse.y 21 Jul 2015 11:04:06 - 1.7 +++ parse.y 21 Jul 2015 11:55:59 - @@ -198,27 +198,27 @@ yylex(void) repeat: c = getc(yyfp); switch (c) { - case ' ': - case '\t': - goto repeat; /* skip spaces */ - case '\\': - next = getc(yyfp); - if (next == '\n') - goto repeat; - else - c = next; - case '\n': - case '{': - case '}': - return c; - case '#': - while ((c = getc(yyfp)) != '\n' && c != EOF) - ; /* skip comments */ - if (c == EOF) - return 0; - return c; - case EOF: + case ' ': + case '\t': + goto repeat; /* skip spaces */ + case '\\': + next = getc(yyfp); + if (next == '\n') + goto repeat; + else + c = next; + case '\n': + case '{': + case '}': + return c; + case '#': + while ((c = getc(yyfp)) != '\n' && c != EOF) + ; /* skip comments */ + if (c == EOF) return 0; + return c; + case EOF: + return 0; } while (1) { switch (c) {
Re: doas failsafe
"tekk" writes: > I've never used a fully qualified path with doas and it works just fine. > ("doas mount", "doas pkg_add", "doas mg".) Do you mean in the config file > or something? Requiring you to specify a full path on filtered commands > or whatever? This may just be a recent change though, I only updated > my system 2 days ago. Ok my bad (again): as advised by the man page, I used an absolute path as command in /etc/doas.conf: permit nopass :wheel cmd /sbin/mount with this, I should "doas /sbin/mount". Changing to: permit nopass :wheel cmd mount works as you said. -- Manuel Giraud
Re: Weak Diffie-Hellman default in nginx port
On Tue, Jul 21, 2015 at 12:31:33PM +0200, lophos wrote: > The nginx config (although disabled by default) supports weak Diffie Hellman > cipher according to ssllabs.com test > (Grade B). > You'd better generate stronger DH-param than disable DHE.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
sam cmpct.info> writes: > How about you release the Brainy Code Scanner then? > > "I have so many bugs; in fact, there are so many, I don't even have the > time to report them! My scanner is so good!" > > Or perhaps you should report 'just' the relatively important ones? Made my day. Searching for bugs is for brainy. Victims of propaganda don't even search archives.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Tue, 21 Jul 2015 11:31:44 +0200 Maxime Villard wrote: > Found by The Brainy Code Scanner. > > It is not the last bug Brainy has found, but it is the last one I > report. I don't have time for that. > How about you release the Brainy Code Scanner then? "I have so many bugs; in fact, there are so many, I don't even have the time to report them! My scanner is so good!" Or perhaps you should report 'just' the relatively important ones? > Maxime >
Weak Diffie-Hellman default in nginx port
Hello. I want to suggest this patch for /etc/nginx/nginx.conf in OpenBSD 5.7. The nginx config (although disabled by default) supports weak Diffie Hellman cipher according to ssllabs.com test (Grade B). --- nginx.conf Tue Jul 21 12:18:44 2015 +++ nginx.conf Tue Jul 21 10:52:27 2015 @@ -114,7 +114,7 @@ #ssl_session_timeout 5m; #ssl_session_cacheshared:SSL:1m; -#ssl_ciphers HIGH:!aNULL:!MD5:!RC4; +#ssl_ciphers HIGH:!aNULL:!MD5:!RC4:!DHE; #ssl_prefer_server_ciphers on; #}
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Ville Valkonen gmail.com> writes: > On Jul 21, 2015 9:32 AM, "Maxime Villard" m00nbsd.net> wrote: > > It is not the last bug Brainy has found, but it is the last one I > > report. I don't have time for that. > > > > Maxime > > Why such a dramatic tone? Because that famous "thank you small people" sounds more and more ridiculous (some says Goebels'ish), no?
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Jul 21, 2015 9:32 AM, "Maxime Villard" wrote: > > Hi, > I put here a bug among others: > > - sys/kern/kern_exec.c - > > char *pathbuf = NULL; > > [...] > > pathbuf = pool_get(&namei_pool, PR_WAITOK); > > [...] > > /* setup new registers and do misc. setup. */ > if (pack.ep_emul->e_fixup != NULL) { > if ((*pack.ep_emul->e_fixup)(p, &pack) != 0) > goto free_pack_abort; > } > > [...] > > free_pack_abort: > free(pack.ep_hdr, M_EXEC, 0); > exit1(p, W_EXITCODE(0, SIGABRT), EXIT_NORMAL); > > /* NOTREACHED */ > atomic_clearbits_int(&pr->ps_flags, PS_INEXEC); > if (pathbuf != NULL) > pool_put(&namei_pool, pathbuf); > > return (0); > } > > > > 'pathbuf' is leaked. > > This path being obviously reachable from userland, it is easy for a > local (un)privileged user to cause the kernel to run out of memory and > become unresponsive. OpenBSD 5.7 is affected, and quite certainly > previous releases. > > Exploit here: > > http://m00nbsd.net/garbage/OpenBSD_execve-DoS.txt > > You can see with vmstat -m that the namei pool becomes enormous. > > Found by The Brainy Code Scanner. > > It is not the last bug Brainy has found, but it is the last one I > report. I don't have time for that. > > Maxime Why such a dramatic tone? -- Ville
Re: doas failsafe
On Mon, Jul 20, 2015 at 11:58:34PM -0700, Manuel Giraud wrote: > > "Ted Unangst" writes: > > > Manuel Giraud wrote: > >> Hi, > >> > >> I've just shot myself in the foot after /etc/doas.conf tweaking. This > >> patch adds a failsafe "permit :wheel" rule in case of syntax error. Is > >> this safe enough? Should it be done elsewhere (with some kind of > >> visudo)? > > > > I think the failsafe is "run su". Since it is possible to configure doas to > > even less than "permit :wheel" this would in some cases be a fail > > open. > > You're right. I forgot about su and should have asked first. Another > question before I give this a shot: doas requires an absolute path for > command, is it feature or a behaviour that can be modified (i.e. I > prefer to type "doas mount" instead of "doas /sbin/mount")? > -- > Manuel Giraud > I've never used a fully qualified path with doas and it works just fine. ("doas mount", "doas pkg_add", "doas mg".) Do you mean in the config file or something? Requiring you to specify a full path on filtered commands or whatever? This may just be a recent change though, I only updated my system 2 days ago.
Brainy: User-Triggerable Kernel Memory Leak in execve()
Hi, I put here a bug among others: - sys/kern/kern_exec.c - char *pathbuf = NULL; [...] pathbuf = pool_get(&namei_pool, PR_WAITOK); [...] /* setup new registers and do misc. setup. */ if (pack.ep_emul->e_fixup != NULL) { if ((*pack.ep_emul->e_fixup)(p, &pack) != 0) goto free_pack_abort; } [...] free_pack_abort: free(pack.ep_hdr, M_EXEC, 0); exit1(p, W_EXITCODE(0, SIGABRT), EXIT_NORMAL); /* NOTREACHED */ atomic_clearbits_int(&pr->ps_flags, PS_INEXEC); if (pathbuf != NULL) pool_put(&namei_pool, pathbuf); return (0); } 'pathbuf' is leaked. This path being obviously reachable from userland, it is easy for a local (un)privileged user to cause the kernel to run out of memory and become unresponsive. OpenBSD 5.7 is affected, and quite certainly previous releases. Exploit here: http://m00nbsd.net/garbage/OpenBSD_execve-DoS.txt You can see with vmstat -m that the namei pool becomes enormous. Found by The Brainy Code Scanner. It is not the last bug Brainy has found, but it is the last one I report. I don't have time for that. Maxime
Re: doas failsafe
> Less code running with setuid root, the better. That is the entire point.
Re: doas failsafe
2015-07-21 10:56 GMT+02:00 Theo de Raadt : >> Ability to define alias in the doas config file might be nice. Just >> like ssh with the ssh_config file. > > I have always wanted a .lsrc file, which would allow me to override > the special options for ls, as well. That's kind of what you are > talking about, right? > > No, I think you are serious. > > And so let's say code is written to support an alias. And let's > say it has a bug. It runs as setuid root. > > Do you understand what happens next? > > If you want software to do everything, eventually it will do everything > including what you cannot afford. > To be honest, I haven't thought about what would happen if there is a bug. The idea was to allow a set of key which would be replaced with another value. Nothing more. I would call 'doas pkg' and doas would work with /usr/sbin/pkg_add instead of pkg. But it is a better idea to let the job of expand value to the shell. Less code running with setuid root, the better. Thanks for correcting me.
Re: doas failsafe
> Ability to define alias in the doas config file might be nice. Just > like ssh with the ssh_config file. I have always wanted a .lsrc file, which would allow me to override the special options for ls, as well. That's kind of what you are talking about, right? No, I think you are serious. And so let's say code is written to support an alias. And let's say it has a bug. It runs as setuid root. Do you understand what happens next? If you want software to do everything, eventually it will do everything including what you cannot afford.
Brainy: Use-After-Free in if_bnx
Hi, I put here a bug among others: -- sys/dev/pci/if_bnx.c if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) && !(sc->rx_mode & BNX_EMAC_RX_MODE_KEEP_VLAN_TAG)) { #if NVLAN > 0 DBPRINT(sc, BNX_VERBOSE_SEND, "%s(): VLAN tag = 0x%04X\n", __FUNCTION__, l2fhdr->l2_fhdr_vlan_tag); m->m_pkthdr.ether_vtag = l2fhdr->l2_fhdr_vlan_tag; m->m_flags |= M_VLANTAG; #else m_freem(m); goto bnx_rx_int_next_rx; #endif } bnx_rx_int_next_rx: sw_prod = NEXT_RX_BD(sw_prod); } sw_cons = NEXT_RX_BD(sw_cons); /* If we have a packet, pass it up the stack */ if (m) { sc->rx_cons = sw_cons; DBPRINT(sc, BNX_VERBOSE_RECV, "%s(): Passing received frame up.\n", __FUNCTION__); ml_enqueue(&ml, m); DBRUNIF(1, sc->rx_mbuf_alloc--); sw_cons = sc->rx_cons; } Use-after-free with 'm'. Found by The Brainy Code Scanner. Maxime
Re: doas failsafe
2015-07-21 8:58 GMT+02:00 Manuel Giraud : > "Ted Unangst" writes: > >> Manuel Giraud wrote: >>> Hi, >>> >>> I've just shot myself in the foot after /etc/doas.conf tweaking. This >>> patch adds a failsafe "permit :wheel" rule in case of syntax error. Is >>> this safe enough? Should it be done elsewhere (with some kind of >>> visudo)? >> >> I think the failsafe is "run su". Since it is possible to configure doas to >> even less than "permit :wheel" this would in some cases be a fail >> open. > > You're right. I forgot about su and should have asked first. Another > question before I give this a shot: doas requires an absolute path for > command, is it feature or a behaviour that can be modified (i.e. I > prefer to type "doas mount" instead of "doas /sbin/mount")? Ability to define alias in the doas config file might be nice. Just like ssh with the ssh_config file. -- Cordialement, Coues Ludovic +336 148 743 42