end in the past, AFAIR,
where we were committing fixes and later publish SAs - the time between
commit and SA publication gave a room to people to make those kind of
accusations. This is the reason we now try to commit fix and publish SA
at the same time, isn't it?
--
Pawel Jakub Dawidek
on it.
On Tue, Oct 25, 2016 at 10:47:44PM -0700, Xin LI wrote:
> It's unprivileged local DoS (if it's root DoS then we normally don't).
>
> On Tue, Oct 25, 2016 at 9:27 PM, Pawel Jakub Dawidek wrote:
> > Hi guys,
> >
> > since when do we publish securit
dG0RZWyT/WXsEHlv5NiXVMPML+oY918jppqClkoO
> pwjcneWTqgYrE4vvVOADKOlWyNa4jFmPQSW7MmNEaF4RMd8TMcE/cBTKOi41YuOp
> la1JzvtWUnou7oQqy/xKr0S/Wa2x6ZhR4vBg28fkfrQhn55N+qqDicQ3F907dOm5
> A0ERHKgImlWSGM+Sf2CJyrUJUNUye0bVQMhrM4e3psZ7Jr20IXjnhppr1mufCjTH
> H+aEHv43o/1HuoltnjstiBZ/CZpFdIXkBpsHtzteZR2y+pmZFA9bB
On Mon, Mar 17, 2014 at 06:09:04PM -0700, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 03/17/14 02:26, Pawel Jakub Dawidek wrote:
> > On Thu, Mar 13, 2014 at 02:08:36PM -0700, Xin Li wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Hash:
+
> if (dup2(fd, STDIN_FILENO) == -1)
> errx(1, "Unable to cover stdin");
> if (dup2(fd, STDOUT_FILENO) == -1)
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
pgpjrI34y2PCW.pgp
Description: PGP signature
%
> > (Student's t, pooled s = 0.683428)
> >
> > This is in preperation of bringing in an SSE4 accelerated version of
> > sha256 (for both userland and kernel) that sees a 2x performance
> > increase.
I can't wait:)
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
pgpNt2CU3BsUS.pgp
Description: PGP signature
tsockopt() and its behavior depends on external code (which also
> doesn't exist not, but could be written in future). If we enter capsicum
> with this option (although, I'm sure it's not widely used) this (future)
> external code may not work completely, since capsicum i
py.sh (revision 259828)
> +++ libexec/save-entropy/save-entropy.sh (working copy)
> @@ -42,6 +42,10 @@ elif [ -r /etc/rc.conf ]; then
> . /etc/rc.conf 2>/dev/null
> fi
>
> +if [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ]; then
> + exit 0
> +fi
>
On Mon, Jun 10, 2013 at 06:07:17PM -0500, Brooks Davis wrote:
> On Sun, Jun 09, 2013 at 12:33:46AM +0200, Pawel Jakub Dawidek wrote:
> > I'd appreciate any review, especially security audit of the proposed
> > changes. The new and most critical function is probably send_pack
s are here. Every change has individual description:
http://people.freebsd.org/~pjd/patches/dhclient_capsicum.patches
I'd appreciate any review, especially security audit of the proposed
changes. The new and most critical function is probably send_packet_priv().
--
Pawel Jak
On Tue, Sep 25, 2012 at 12:58:37PM +0200, Dag-Erling Smørgrav wrote:
> Pawel Jakub Dawidek writes:
> > Note that this fake data is the hardest to gather entropy from, as it
> > doesn't interact with any external hardware. I'm all for testing it on
> > real hard
ting it on
real hardware and I expect to be able to gather even more entropy from
it (so discarding less than top 7 bits). The problem with making
observations during boot takes much, much longer, so it will limit the
number os samples significantly, and as you know the more samples the
b
available entropy, which is bad, but I
think better than not providing any entropy this method. On the other
hand having it on one or two platforms only would maybe motivate people
to verify it on other platforms.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD commit
On Sun, Sep 23, 2012 at 02:37:48AM +0200, Mariusz Gromada wrote:
> W dniu 2012-09-22 21:53, Pawel Jakub Dawidek pisze:
> > Mariusz, can you confirm my findings?
>
> Pawel,
>
> Your conclusions can be easily confirmed by shape analysis of the EDF.
> Usually maximum quant
On Sat, Sep 22, 2012 at 10:03:23AM +0200, Pawel Jakub Dawidek wrote:
> If discarding top ten bit in case of such dummy driver is enough, we
> could probably discard less from drivers that interact with real
> hardware, but even with 43 device_attach() calls during boot on similar
>
On Thu, Sep 20, 2012 at 07:58:51AM -0400, John Baldwin wrote:
> On Thursday, September 20, 2012 6:21:04 am Pawel Jakub Dawidek wrote:
> > I agree, we should do such analysis for much more devices and different
> > kind of devices. A platform might be an important factor as well.
&g
On Wed, Sep 19, 2012 at 07:28:36PM +0100, RW wrote:
> On Tue, 18 Sep 2012 23:14:22 +0200
> Pawel Jakub Dawidek wrote:
>
> > Hi.
> >
>
> > The patch is here:
> >
> > http://people.freebsd.org/~pjd/patches/harvest_device_attach.patch
>
On Thu, Sep 20, 2012 at 11:08:15PM -0700, David O'Brien wrote:
> On Fri, Sep 21, 2012 at 07:35:49AM +0200, Pawel Jakub Dawidek wrote:
> > Note that adding sysctl to turn off entropy harvesting from
> > device_attach() is pretty useless, as sysctls can be changed once we
> &g
On Wed, Sep 19, 2012 at 03:34:59PM -0700, David O'Brien wrote:
> On Tue, Sep 18, 2012 at 11:14:22PM +0200, Pawel Jakub Dawidek wrote:
> > I experimented a bit with collecting entropy from the time it takes for
> > device_attach() to run (in CPU cycles). It seems that those t
On Wed, Sep 19, 2012 at 11:10:51PM +0100, RW wrote:
> On Wed, 19 Sep 2012 22:53:32 +0200
> Pawel Jakub Dawidek wrote:
>
>
> > Here's how the distribution looks like for device_attach() times of my
> > sound card. The times were 26bit numbers, so this is after disca
On Wed, Sep 19, 2012 at 09:29:23PM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
> > > If all the times are more or less equally probable in this range […]
> >
> > They're very unlikely to be equally probab
On Wed, Sep 19, 2012 at 08:59:15PM +0100, Ben Laurie wrote:
> On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek wrote:
> > On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
> >> > If all the times are more or less equally probable in this range […]
&
0.1% of
the attach time to be unpredictable (the attach time in most cases vary
by few percent, not sure yet how much of this variation is really
unpredictable).
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Comments?
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
pgpTmc5qFwQUn.pgp
Description: PGP signature
dd of=/dev/random bs=8k 2>/dev/null
> - /sbin/sha256 -q `sysctl -n kern.bootfile` \
> - | dd of=/dev/random bs=8k 2>/dev/null
> + for cmd in "kenv" "dmesg" "df -ib" "ps -fauxww" "date" "sysctl -
random_harvest_internal() is used for both and it is trying to
be fast, as we don't want to slow down the caller. But with /dev/random
the caller won't mind to be slowed down.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer
gree that we should
fix yarrow, /dev/random or whatever is dropping the input after 4kB.
If we can't do that, then we should hash it with sha512 this way the
entropy will be reduced to 512 bits (if there is more entropy in the
input) which should be enough for yarrow to be happy.
Also note
g
were fixed and improvement were made to the audit framework in FreeBSD,
which also have to be merged.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tu
On Sat, Jun 09, 2012 at 11:51:41AM +0300, Gleb Kurtsou wrote:
> On (31/05/2012 21:48), Pawel Jakub Dawidek wrote:
> > As learned on someone else's mistakes, I'd like to ask for a review of
> > those changes related to random data handling:
> >
> > h
d of three system calls (open, read and
close) we use only one (__sysctl).
The second patch enables the use of libc's arc4random(3) in OpenSSL.
After implementing the first one I found that OpenBSD's arc4random(3)
also uses sysctl, but without fall back to /dev/random.
--
s one should use standard UNIX permissions and ACLs.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
pgpWfIDKqEsXh.pgp
Description: PGP signature
balabit.com/network-security/scb
Or similar (but much nicer) solution from a FreeBSD-friendly company:)
http://www.wheelsystems.com/products/products_fudo/spec?lang=en
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com
pgpmou205vMkq.pgp
Description: PGP signature
FYI, it looks like HAST is the first capsicum consumer in the base.>:>
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://yomoli.com
--- Begin M
ow be loaded from a file (-J and -j options).
--
Pawel Jakub Dawidek http://www.wheelsystems.com
p...@freebsd.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgpn3ZfL0xo1z.pgp
Description: PGP signature
t password
used for encryption, so all you want to protect it against is theft of
/etc/master.passwd.
All in all static passwords are for the weak that's why we
(Wheel Systems) believe in easy to use one-time passwords:)
--
Pawel Jakub Dawidek http://www.wheel
is
> attack, and whether it makes sense to chroot superuser processes on FreeBSD.
Superuser running inside chroot(2) has many ways to escape. You
bascially gain no additional security in chrooting a process that will
continue to operate with privileges.
You should either chroot and drop privileges
On Wed, Mar 14, 2007 at 01:59:18PM +0100, Pawel Jakub Dawidek wrote:
> Hi.
>
> I'd like to commit this patch:
>
> http://people.freebsd.org/~pjd/patches/vfs_mount.c.9.patch
>
> It currently should change nothing, but will be needed once we allow to
> grant p
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgpPP1AV6hiuH.pgp
Description: PGP signature
On Tue, Jan 23, 2007 at 01:25:08PM +0100, Alexander Leidinger wrote:
> Quoting Pawel Jakub Dawidek <[EMAIL PROTECTED]> (from Tue, 23 Jan 2007
> 12:34:44 +0100):
> >It looks like it may work, but I still find it a bit risky. If sh(1) can
> >reopen the file under some cond
On Sat, Jan 20, 2007 at 03:24:23PM +0100, Alexander Leidinger wrote:
> Quoting Pawel Jakub Dawidek <[EMAIL PROTECTED]> (Sat, 20 Jan 2007 14:03:08
> +0100):
>
> > I fully agree that console.log should be outside a jail. At least noone
> > proposed safe solution so far
ree that console.log should be outside a jail. At least noone
proposed safe solution so far, which also means it's not an easy fix.
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer
Dirk's proposal is to create a file with mktemp(1) in the
same directory where we're going to rename(2) the file, but I don't
think mktemp(1) will be safe here:
good-guyattacker-within-a-jail
cd /jail/var/log
mktemp foo.XXX
On Mon, Jan 15, 2007 at 10:15:26PM +0100, Dirk Engling wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pawel Jakub Dawidek wrote:
>
> > In other words, it may break existing configurations.
>
> Sorry, I meant "pwd -P" and assumed that, accord
On Mon, Jan 15, 2007 at 08:56:44PM +0100, Dirk Engling wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pawel Jakub Dawidek wrote:
>
> > I'll keep /var/log/console.log outside a jail, because using
> > 'realpath -c' will be dangerous once
ce the jail is running. There could be
a race where `realpath -c` returns one path, an attacker inside a jail
changes one of resolved path's component and rc.d/jail from outside a
jail tries to use it.
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgpToYrOw36TQ.pgp
Description: PGP signature
e end I decided to go ahead with
> this advisory largely because we were already planning on issuing an advisory
> this week (for a far more serious issue in GNU tar), but if a similar issue
> arises next month, we might decide not to bother with an advisory.
That's why IMHO it was a mi
On Wed, Sep 06, 2006 at 03:22:36PM -0700, Network Security wrote:
> GELI even properly installed has some security problems, [...]
Very strong words, care to elaborate?
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] h
thentication process.
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgpCryIdEUXE7.pgp
Description: PGP signature
On Mon, Apr 24, 2006 at 10:50:37AM -0400, Mike Tancsa wrote:
+> At 10:27 AM 24/04/2006, Pawel Jakub Dawidek wrote:
+> >On Sun, Apr 23, 2006 at 09:16:13PM +0200, Oliver Fromme wrote:
+> >+> Winston Tsai <[EMAIL PROTECTED]> wrote:
+> >+> > I got roughly the sam
AES192 and
AES256 with cryptodev. The patch which fix this is available here:
http://people.freebsd.org/~pjd/patches/hw_cryptodev.c.patch
PS. For AES128 cryptodev can be used without the patch.
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED]
t;(e.g., UDP) are used, this may have a variety of effects.
+>
+> As far as I understood, only systems which use "options FAST_IPSEC" are
affected by this issue. Is it true? If so, wouldn't be wise to stress this
+> fact in the advisory?
Yes, only
u had problems with this, you may want to try again.
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgpl5SL6TCzIG.pgp
Description: PGP signature
(keyfile).
+> But that would render a possible bruteforce entry.
Even when you use passphrase only, geli(8) provides PKCS#5v2 to
strength it.
I'm using it with 131072 iterations, so it is 2^17 times harder to
brute-force my passphrase and takes about 2-3 seconds to attach
encrypted dev
sers, I think that's a bug that'd need fixing.
sysctl security.bsd.unprivileged_read_msgbuf=0
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
ements (managing keys, protecting passphrases,
metadata backups, encrypted root partition, etc.) are or could be the same.
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgpwHua2MTvme.pgp
Description: PGP signature
em:)
I'm not going to commit it by myself.
--
Pawel Jakub Dawidek http://www.wheel.pl
[EMAIL PROTECTED] http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
pgpPiL2FQcpq9.pgp
Description: PGP signature
e bootloader). The passphrase is entered at the bootloader prompt
+> or embedded in the bootloader.
This is not not possible with current GBDE.
I've patches which allows this here:
http://people.freebsd.org/~pjd/patches/gbde.patch
--
Pawel Jakub Dawidek http://www
On Sun, Jul 24, 2005 at 04:06:02PM +0200, Poul-Henning Kamp wrote:
+> In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writes:
+>
+> >We should probably test entropy quality on boot.
+> >I've somewhere userland version of /sys/dev/rndtest/ which implements
+>
ses from outside a jail can bind to
port 80. We can change this behaviour to "allow port 80 to be used
only inside a jail 1". This will be a warning for not jailed
processes (don't use this port, because it can be used in a jail
which will overwrite your service).
59 matches
Mail list logo
