-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 the jail is running. There could be
> a race where `realpath -c` returns one path, an attacker inside a jail
> changes one
-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, according to pwds man page, to
be default.
>> cd ${jail_root}
>> j_root=`pwd`
>> cd ${jail_var_log_dir}
>> j_var_log=`pwd`
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pawel Jakub Dawidek wrote:
> On Mon, Jan 15, 2007 at 10:15:26PM +0100, Dirk Engling wrote:
>>>> cp -f ${temp_log} console.log
> console.log can still be a softlink. I don't see option for cp(1) which
> allows to not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Colin Percival wrote:
> No. `cp -f` unlinks the existing file and creates a new file, but will
> still follow a symlink if one is created between the "unlink" syscall and
> the "open" syscall.
>
> /* remove existing destination f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pawel Jakub Dawidek wrote:
> When -J operates on a file inside a jail, it create the same security
> hole as the one from security advisory, because it opens a file before
> calling jail(2).
> I fully agree that console.log should be outside a jail. A
On 13.04.13 20:29, Pétur Ingi Egilsson wrote:
> I noticed that if I execute the following code, then the program is
> able to read the file even if the files' permissions are changed around
> the /mark/ section in such a way that the UID under which the program is
> running should not have any per
On 08.04.14 15:45, Mike Tancsa wrote:
> I am trying to understand the implications of this bug in the
> context of a vulnerable client, connecting to a server that does not
> have this extension. e.g. a client app linked against 1.xx thats
> vulnerable talking to a server that is running some
On 08.04.14 20:05, Nathan Dorfman wrote:
> Someone please correct me if I'm wrong, but I think simply adding
> -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is
> sufficient to remove the vulnerability from the base system.
You forgot to mention installing, but yes.
erdge
Out of curiosity:
have those findings officially been reported? Is someone working on them?
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
If not, shall I extract them?
Maybe we should start an "audit a subsystem" week ;)
On 03.01.18 22:14, Ed Maste wrote:
> The FreeBSD Security Team recently learned of the details of these
> issues that affect certain CPUs.
Can you say, at what day you were informed?
erdgeist
___
freebsd-security@freebsd.org mailing list
https://list
10 matches
Mail list logo
