> On 16 Jun 2021, at 00:39, Martin Pieuchot wrote:
>
> On 15/06/21(Tue) 22:52, David Gwynne wrote:
>> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
>>> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
>> [...]
The in6_ functions need netlock. And driver SIOCSIFFLAGS
> On 16 Jun 2021, at 01:10, Scott Cheloha wrote:
>
> Hi,
>
> dlg@ just moved nsecuptime() and getnsecuptime() into kern_tc.c.
>
> To tidy it up I'd like to refactor the fraction-to-nanosecond and
> bintime-to-nanosecond conversions into new functions so we only need
> to write them once.
> On 14 Jun 2021, at 19:12, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
> looks good to me. I think this should be committed
> as-is. I have just one question,
>
> On Mon, Jun 14, 2021 at 01:58:06PM +1000, David Gwynne wrote:
>
>> @@ -1931,6 +1933,9 @@ pfsync_defer(struct pf_state *st,
I have a patch on tech@ to raise the setitimer(2) input limit to
UINT_MAX seconds:
https://marc.info/?l=openbsd-tech=162343190813127=2
After that is committed, I'm unclear whether alarm(3) can fail anymore
on OpenBSD. The only remaining plausible failure case I can see is
EFAULT. But I'm
Hello,
>
> as above, copyout with a sleeping lock is fine.
>
> the whole point of my change is to give us the ability to lock in the
> forwarding path separately to locking in the ioctl path. half of that is
> so we can copyout safely. the other half is to avoid letting the ioctl
> path block
> On Jun 15, 2021, at 11:08 AM, dz...@disroot.org wrote:
>
> A presentation is going to have a bigger effect on people than docs.
> That's the point of it.
You must lead an interesting life full of surprises.
June 15, 2021 8:45 PM, "Dave Voutila" wrote:
> The first link was to the paper:
>
> "A systematic analysis of the science of sandboxing"
> Maass, et.al. (2016). PeerJ Computer Science 2:e43
>
> It is most certainly not paywalled. Maybe you can try this one?
>
>
A friendly weekly ping.
Thanks,
Ash
Ashton Fagg writes:
> I have been working on fixing an issue (which was partially fixed by a
> diff I sent in earlier this year) with iscsid. With iscsi disks in
> /etc/fstab, sometimes the devices aren't fully up and ready before fsck
> tries to run -
In my work environment SNMPv3 auth+enc is the only method allowed.
-Original Message-
From: owner-t...@openbsd.org On Behalf Of Stuart
Henderson
Sent: Tuesday, June 15, 2021 10:40 AM
To: Martijn van Duren
Cc: tech
Subject: [EXTERNAL] Re: Fix unsafe snmpd defaults
Can we take a straw
June 15, 2021 7:32 PM, "Claudio Jeker" wrote:
>> [...] It's on the official domain, so I've assumed that it was a
>> trustworthy source - I guess not? Did a hacker put it there?
> You are just trolling around.
Sorry, I was just a bit salty because of that "paper" about sandboxes.
The main point
Hi,
I didn't want to reply, but I saw all this thread and had to because it seems
you're on some fumes dude.
I surely knew before and after my commit that the unveil wound't descend into
the child process, what happened in this case was that I actually didn't see
that the main process actually
On Tue, Jun 15, 2021 at 10:10:54AM -0500, Scott Cheloha wrote:
>
> [...]
>
> To tidy it up I'd like to refactor the fraction-to-nanosecond and
> bintime-to-nanosecond conversions into new functions so we only need
> to write them once.
>
> ok?
Updated diff. We can also use BINTIME_TO_NSEC()
>> And I am not letting someone write to the filesystem. Yet, they can
>> bypass that easily. `unveil("/", "rx")` gives a false illusion of
>> security, which can even trip up OpenBSD maintainers (more below).
>
> That statement has a precise meaning, so I disagree. The unveil manual
> page does
dz...@disroot.org writes:
> June 15, 2021 7:32 PM, "Claudio Jeker" wrote:
>>> [...] It's on the official domain, so I've assumed that it was a
>>> trustworthy source - I guess not? Did a hacker put it there?
>> You are just trolling around.
> Sorry, I was just a bit salty because of that
I'll await further responses, but some things inline.
On Tue, 2021-06-15 at 17:39 +0100, Stuart Henderson wrote:
> > > > - if the concern is amplification attacks then setting the minlevel to
> > > > authpriv is too high, since you'll silently break logins for users
> > > > that miss the
June 15, 2021 2:51 PM, "Theo de Raadt" wrote:
> "attacker"?
Isn't the purpose of pledge() and unveil() to prevent a person with
a code execution bug from damaging the system?
> Seems to be working as intended. You are letting someone run all binaries.
And I am not letting someone write to the
On Tue, Jun 15, 2021 at 07:25:30PM +0200, Florian Obser wrote:
> On 2021-06-15 17:39 +01, Stuart Henderson wrote:
> > Can we take a straw poll of readers of this email who are using SNMPv3
> > (if any ;-) -- are you using auth+enc, just auth, or no authentication?
> > I'm thinking that somebody
On Tue, Jun 15, 2021 at 04:33:19PM +, dz...@disroot.org wrote:
> >> And I am not letting someone write to the filesystem. Yet, they can
> >> bypass that easily. `unveil("/", "rx")` gives a false illusion of
> >> security, which can even trip up OpenBSD maintainers (more below).
> >
> > That
On 2021-06-15 17:39 +01, Stuart Henderson wrote:
> Can we take a straw poll of readers of this email who are using SNMPv3
> (if any ;-) -- are you using auth+enc, just auth, or no authentication?
> I'm thinking that somebody who went to the trouble of using v3
> probably uses auth+enc though I
> > > - if the concern is amplification attacks then setting the minlevel to
> > > authpriv is too high, since you'll silently break logins for users
> > > that miss the enckey parameter.
> > > I changed this to always default to seclevel auth.
> >
> > I do still think enc is the safer
The Adj-RIB-Out should show what is sent to the peer. bgpd did not fully
do that since it adjusted the ASPATH and the nexthop afterwards when
building the actual UPDATE.
This diff changes that and moves the ASPATH prepend for ebgp sessions and
the selection of the nexthop. Thanks to this the
> "Theo de Raadt" wrote:
> Have you found anything which implies that unveil persists?
I haven't found anything which implies that unveil doesn't persist either.
Do you think that the documentation should keep developers guessing?
> unveil and pledge exist for a process to *PROTECT AGAINST IT'S
Hi,
dlg@ just moved nsecuptime() and getnsecuptime() into kern_tc.c.
To tidy it up I'd like to refactor the fraction-to-nanosecond and
bintime-to-nanosecond conversions into new functions so we only need
to write them once.
ok?
Index: sys/time.h
dz...@disroot.org wrote:
> June 15, 2021 2:51 PM, "Theo de Raadt" wrote:
> > "attacker"?
> Isn't the purpose of pledge() and unveil() to prevent a person with
> a code execution bug from damaging the system?
No, the purpose is to declare the bounds of what a program does.
So to answer your
On 15/06/21(Tue) 22:52, David Gwynne wrote:
> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
> > On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> [...]
> > > The in6_ functions need netlock. And driver SIOCSIFFLAGS ioctl
> > > must not have splnet().
> >
> > Why not? This is
I made this patch with the help of pardis at IRC. This gives support for UGREEN
USB to Serial RS-232 based on Prolific PL2303.
Index: uplcom.c
===
RCS file: /cvs/src/sys/dev/usb/uplcom.c,v
retrieving revision 1.77
diff -u -p -u -p
On Tue, 2021-06-15 at 00:30 +0100, Stuart Henderson wrote:
> On 2021/06/14 19:40, Martijn van Duren wrote:
> > On Mon, 2021-06-14 at 12:55 +0100, Stuart Henderson wrote:
> > > By default, snmpd responds to the frequently abused community strings
> > > "public" and "private".
> > >
> > > To
On Mon, Jun 14, 2021 at 11:44:15PM +0200, Martin Pieuchot wrote:
> On 14/06/21(Mon) 13:45, Visa Hankala wrote:
> > When a knote's kn_status is updated, it is necessary to lock the kqueue
> > that owns the knote, to ensure proper serialization. filt_proc() has
> > a mistake in this, and the
On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> > Hi,
> >
> > I have seen this crash trace on a 6.6 based system, but I think the
> > bug exists still in -current. It happened when an ixl(4) interface
> > was removed from
dz...@disroot.org wrote:
> > If you use "exec", you have intentionally and visibly opened an escape
> > hatch to run other programs, which are EXPECTED to self-protect against
> > their own misbehaviour.
> Yet, the documentation doesn't warn about it. It's an easy mistake to make.
> Let's say
The expected uses of unveil and pledge aren't some weird fiction
of "oh look I can use them wrong".
The interesting cases are when pledge and unveil are used correctly,
which means they reduce control or access to objects.
This is expecially true around pledge "proc exec".
Say you have program1
On Tue, Jun 15, 2021 at 11:21:03AM +, dz...@disroot.org wrote:
> > "Theo de Raadt" wrote:
> > Have you found anything which implies that unveil persists?
> I haven't found anything which implies that unveil doesn't persist either.
> Do you think that the documentation should keep developers
On Tue, Jun 08, 2021 at 06:54:25PM +0200, Alexandr Nedvedicky wrote:
> Hello David,
>
> I'm still not sure if your change is ultimate fix, or just significantly
> minimizes risk of the bug. If I understand things right, the problem we are
> trying to solve:
> DIOCGETSTATES we have in
On Mon, Jun 14, 2021 at 05:35:07PM +0200, Mark Kettenis wrote:
> > Date: Mon, 14 Jun 2021 11:50:24 +0200
> > From: Martin Pieuchot
> >
> > Now that operations on amaps are serialized using a per-map rwlock
> > the KERNEL_LOCK() shouldn't be necessary to call amap_unref(). The
> > diff below
34 matches
Mail list logo
