On 24 Feb 2012 at 10:32, "Tóth Attila" wrote:
> Even after change to another user (mail or dovecot). It seems the kernel
> incorrectly recognized the change of the UID.
wasn't that already fixed with:
commit 4fd554e3a097b22c5049fcdc423897477deff5ef
Author: Brad Spengler
Date: Mon Feb 20 09:17:
On 15 Feb 2012 at 21:23, Alex Efros wrote:
> So, I've just tested hardened vs non-hardened kernels using exactly same
> vmware-modules. Result is same: on hardened kernel vmware reset host,
> on gentoo kernel vmware works ok.
>
> If you've any ideas how to debug/fix this issue - I'm ready to test
On 25 Feb 2012 at 10:09, Christian Apeltauer wrote:
hi,
> The code wasn't exactly the same as expected by firefox's
> ff9-aslr-fix.patch, but I was able to port it to gnash. gnash works
> now. Nonetheless I would like to have my patch to be reviewed by
> someone who has a better understanding of
On 25 Feb 2012 at 14:40, Anthony G. Basile wrote:
> @pipacs, I've had reports of 3.2.2-r1 kernels having problems booting.
> idl0r gave me a bzImage which will not boot in qemu. Using the same
> kernel config, 3.2.7 *will* boot. The problem occurs shortly after
> decompression but before any
On 26 Feb 2012 at 11:01, Christian Apeltauer wrote:
> > while the patch looks good me, can't you simply configure gnash to
> > not use the embedded jemalloc copy but the systemwide one (which was
> > fixed 2 years ago or so)?
>
> I added --disable-jemalloc to $myconf and gnash worked without the
>
On 30 Mar 2012 at 20:12, wrote:
> On Thu, 29 Mar 2012, Sven Vermeulen wrote:
>
> >You can try to make it a valid ELF header first, and then paxmark it.
> >
> >I have the following for my Skype:
> >paxctl -C /opt/skype/skype
> >paxctl -me /opt/skype/skype
>
> I tried running paxctl -Cm on it (sho
about this part:
[22:58:31] blueness: the gcc-plugins fail
[22:58:33] 4.7 just hit the overlay, i can try after the meeting
[22:58:37] i figured
[22:58:52] do you know what the breakage is?
[22:59:42] gcc-4.7 have change some of the plugins api
the problem is that with gcc 4.7 they made the
On 16 May 2012 at 16:39, Hinnerk van Bruinehsen wrote:
> at the moment the thunderbird-ebuild in the tree does a "pax mark m"
> on the binary.
> At least for me thunderbird works fine if I just disable jit.
there're a few packages that define a local 'jit' USE flag, i'd say
thunderbird/firefox/et
On 18 May 2012 at 13:29, RB wrote:
> That's because (as I just found by testing) PAX_KERNEXEC "mitigates"
> the oops. To put it in something of a boolean form, the following
> produces the crashes:
>
> PAX_MEMORY_UDEREF && !(PAX_MEMORY_UDEREF && PAX_KERNEXEC)
do you have any slab debugging opti
On 2 Jun 2012 at 0:39, "Tóth Attila" wrote:
> After upgrading from hardened-sources-3.3.6-r1 to hardened-sources-3.3.7,
> smartd gets killed by PaX upon booting:
>
> Jun 2 00:47:50 kernel: PAX: size overflow detected in function
> ata_cmd_ioctl drivers/ata/libata-scsi.c:488
> Jun 2 00:47:50 kern
On 7 Jun 2012 at 22:04, "Tóth Attila" wrote:
> I'm just wondering about the security implications of the new ABI.
basically that much less entropy in ASLR, otherwise nothing changes i think.
> I guess it needs some extra work for Spender and PaxTeam to port Grseurity
> to 3.4.
i've had mine out
On 10 Jun 2012 at 17:46, René Rhéaume wrote:
> I have a somewhat crazy idea to run JIT code with mprotect enforced:
> instead of putting the generated code into anonymous memory, why not put it
> as a shared library inside a tmpfs, the the host program simply call dlopen
> on it? This way, we woul
On 31 Jul 2012 at 22:12, Michael Orlitzky wrote:
> I get nothing in my dmesg, which otherwise records most limit-based denials.
>
> Is there some way I can troubleshoot this? It works on amd64 with the
> same kernel hardening options.
an strace -f may help to see what exactly fails.
On 1 Aug 2012 at 8:41, Michael Orlitzky wrote:
> Thanks, here are strace -f logs from both the hardened box (where it
> fails) and a vanilla gentoo x86 VM (where it works).
mmap2(NULL, 30720, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 ENOMEM (Cannot allocate memor
On 1 Aug 2012 at 9:56, Michael Orlitzky wrote:
> But, I'd ruled out the stack size limitation because resource oversteps
> are supposed to be reported:
it's not a resource overstep but simply not enough virtual address space
(either because it's too fragmented to fit such a big allocation or the
On 22 Aug 2012 at 1:37, Maxim Kammerer wrote:
> On Tue, Aug 21, 2012 at 11:44 PM, Anthony G. Basile
> wrote:
> > That sounds about right. I'm not hitting this with tor-ramdisk, a tiny
> > ramdisk image for running tor relays, built with latest tor + busybox +
> > hardened kernel. I have PAX_SIZ
On 22 Aug 2012 at 4:59, Maxim Kammerer wrote:
> Yes! :) I did read that post, and what I (probably wrongly) gathered
> from it was that the plugin was developed for 3 years, and finalized
> by Emese Revfy during the last year.
what we did 3 years ago was the macro hack, not much to do with the ne
On 7 Sep 2012 at 14:16, "Tóth Attila" wrote:
> Omitting "-pipe" from CFLAGS didn't help. What else can I try to compile
> these binaries? Are there any PaX or Grsec kernel options with a potential
> influence?
i guess you're using SEGMEXEC which limits the process virtual address space
size to 1.
On 19 Nov 2012 at 11:37, Maxim Kammerer wrote:
> On Mon, Nov 19, 2012 at 2:25 AM, Matthew Thode
> wrote:
> > Originally virtualization was slow on grsec/pax with either uderef or
> > kernexec enabled.
>
> My impression was that UDEREF/KERNEXEC were slow in guest. Is it
> wrong, or did these sett
On 22 Dec 2012 at 12:13, Anthony G. Basile wrote:
> http://dev.gentoo.org/~blueness/zzz/pax-quickstart.xml
>
> It describes pretty much anything. Give it a read and let me know what
> you think should be added.
some notes:
> Note that if you enable both PT_PAX and XATTR_PAX, then the kernel e
On 13 Jan 2013 at 11:28, Michael Orlitzky wrote:
> On 01/12/13 18:16, Anthony G. Basile wrote:
> > Its e1000. This was an unknown issue until just recently. Is supposed
> > to be fixed in the latest 3.7.1-r2. Let me know if it is and I'll drop
> > 3.7.0 in favor of 3.7.1-r2.
>
> Bad news:
>
>
On 22 Jan 2013 at 10:56, Grant wrote:
> google-chrome suffers intermittent crashes on x86 unless I enable
> softmode. Is there any other option to keep it running?
can you get some details on the nature of crashes? any logs perhaps?
if softmode fixes it then it's probably MPROTECT related, did y
On 22 Jan 2013 at 19:44, Grant wrote:
> >> google-chrome suffers intermittent crashes on x86 unless I enable
> >> softmode. Is there any other option to keep it running?
> >
> > can you get some details on the nature of crashes? any logs perhaps?
> > if softmode fixes it then it's probably MPROTE
On 20 Mar 2013 at 10:11, Alex Efros wrote:
> Hi!
>
> On Wed, Mar 20, 2013 at 09:25:07AM +0200, Alex Efros wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=462430
next time add me to the bug if you expect an answer instead of spamming
every possible forum.
> > Any ideas which grsec/pax option
On 20 Mar 2013 at 17:59, Alex Efros wrote:
> Anyway, I've tried 3.8.3, and see no difference at all on 32-bit system:
which grsec is that? the last bits of the fix went in like 2 days ago only,
i think gentoo's ebuild uses an older patch than that. best would be if you
tested the latest grsec you
On 25 Mar 2013 at 9:01, Kfir Lavi wrote:
> Hi,
> I'm looking for a way to reduce glibc code size.
> It can be a way to make system smaller and minimize the impact
> of attack vectors in glibc, as in return-to-libc attack.
study this and draw your conclusions whether the whole exercise is
worth it
On 25 Mar 2013 at 22:35, Kfir Lavi wrote:
> Thanks for sharing this talk. I didn't know that the program image in
> Linux is not randomize by ASLR.
well, that's not quite true these days, even vanilla has logic to
randomize the main executable - provided it's a PIE. it of course
depends on the di
On 29 May 2013 at 1:46, "Tóth Attila" wrote:
> I didn't laugh my ass ofter after discovering that python stopped working
> after upgrade. Especially since the package management system depends on a
> working python instance.
> Right after emerging python-2.7.5:
> paxctl-ng -v /usr/bin/python2.7
>
On 28 May 2013 at 21:29, Anthony G. Basile wrote:
> Unfortunately it is very difficult to find everything that links against
> everything on a system. First there's just a simple logistic problem,
> going through all ELF on a system and running ldd (or readelf -d) is
> time consuming and likel
On 29 May 2013 at 8:31, "Tóth Attila" wrote:
> According to my recent experience, if EMUTRAMP is enabled by a PT_PAX flag
> and there's no XATTR_PAX flag present, the system will listen to the
> PT_PAX flag. Can I influence this behavior to rather use the mentioned
> XATTR_PAX default and don't pa
On 29 Jul 2013 at 6:23, Javier Juan Martínez Cabezón wrote:
> PaX tries to do this modification to rsbac git code:
>
> --- fs/namei.c2013-03-19 01:53:21.091281869 +0100
> +++ fs/namei.c2013-03-19 01:53:31.251281326 +0100
> @@ -3954,7 +3956,14 @@
> len = strlen(link);
> if (len >
On 9 May 2014 at 11:15, Michael Orlitzky wrote:
> > [Fri May 9 11:00:42 2014] PAX: refcount overflow detected in:
> > syslog-ng:21823, uid/euid: 0/0
this is the key message, the REFCOUNT feature triggered as it detected
an overflow somewhere.
> > [Fri May 9 11:00:42 2014] CPU: 2 PID: 21823 Co
On 13 May 2014 at 15:39, Joshua Kinard wrote:
> For me, I never had an actual oops. Just a note in dmesg that pax was
> killing command-line processes at random. Running services didn't seem to
> be affected, but I could go run grep or something and it'd just abruptly
> terminate.
when PaX kill
On 13 Jun 2014 at 16:40, subscr...@gmail.com wrote:
> I suggest a little improvement to the wiki: state the fact that
> user_xattr must be enabled in fstab for the relevant filesystems (at
> least /) as this isn't default AFAIK.
i already forcibly enable the general xattr support in filesystems
On 16 Jul 2014 at 0:47, Alex Efros wrote:
> 2014-07-15_21:38:42.73335 kern.alert: grsec: denied marking stack executable
> as requested by PT_GNU_STACK marking in
> /mnt/storage/games/DungeonDefenders/UDKGame/Binaries/DungeonDefenders-x86 by
> /lib32/ld-2.17.so[ld-linux.so.2:2818] uid/euid:1000
On 29 Aug 2014 at 7:31, Anthony G. Basile wrote:
> On 08/29/14 03:32, Marcin Mirosław wrote:
> > W dniu 29.08.2014 o 01:13, Alex Xu pisze:
> >> On 28/08/14 05:02 PM, Sven Vermeulen wrote:
> >>> On Wed, Aug 27, 2014 at 05:34:20PM +0100, André Aparício wrote:
> I encountered the same problem wi
On 18 Sep 2014 at 15:28, Michel Arboi wrote:
> > 2) The cpu problems seems like a genuine bug.
>
> Still running by the way.
> 21170 pts/2RL+ 7004:37 gradm -L /tmp/learning.logs -O /tmp/policy
> 31255 pts/1RL+ 18605:09 gradm -F -L /tmp/learning.logs -O
> /etc/grsec/policy4
> (I tried b
On 20 Sep 2014 at 13:20, Michel Arboi wrote:
> On Fri, Sep 19, 2014 at 9:09 PM, PaX Team wrote:
> > did you email spender with your problem and logs?
>
> No. What's his e-mail?
i put him on cc in my previous mail, you could have just hit 'reply all'...
On 14 Nov 2014 at 22:05, "Tóth Attila" wrote:
> I would suggest to attach the responsible patch of the missing define only
> and the necessary diff of a given ebuild file. That two files could be
> enough, I guess.
yes and probably choose a better list and/or open a bugzilla entry as i doubt
this
On 18 Dec 2014 at 19:58, Anthony G. Basile wrote:
> > So it works on ext4, but not ext3, even though both have the ext_attr flag
> > on
> > disk. Any difference in kernel support?
> >
>
> Because on ext3 you need to add user_xattr to the mount options. Either
> `mount -o user_xattr` or in fsta
On 14 Dec 2014 at 4:18, "Tóth Attila" wrote:
> I've made an observation long before, that although PT_PAX flags are
> properly handled on my systems, the installed binaries and libraries lack
> XATTR_PAX markings.
first, PaX flags don't matter on libraries at all as only the executable
is used to
On 21 Aug 2015 at 21:14, Anthony G. Basile wrote:
> Anyhow, can people please test 4.1.6. I'll rapid stabilize it but I
> don't want to trade one issue for another.
is there some new issue on 4.1.6 that is not in 4.1.4 or is it just out
of caution?
On 23 Aug 2015 at 8:41, Anthony G. Basile wrote:
> On 8/22/15 4:31 AM, PaX Team wrote:
> > is there some new issue on 4.1.6 that is not in 4.1.4 or is it just out
> > of caution?
>
> Bug 558138. The intel iommu stuff is still causing issues although
> according to the
On 30 Aug 2015 at 21:54, François wrote:
> Thanks for your answer (sorry to respond that late). It actually makes
> sense, I thought there was some *magic* possible.
i wouldn't call it magic but PaX used to provide RANDEXEC:
https://pax.grsecurity.net/docs/randexec.txt
On 7 Sep 2015 at 11:06, René Rhéaume wrote:
> 2015-09-07 10:41 GMT-04:00 PaX Team :
> > i wouldn't call it magic but PaX used to provide RANDEXEC:
> >
> > https://pax.grsecurity.net/docs/randexec.txt
>
> Is RANDEXEC abandoned because it could not be po
On 19 Sep 2015 at 2:06, Alex Efros wrote:
> I've temporary switched to `eselect opengl set xorg-x11` and was able to
> start pidgin, but I wonder is there other way to work around this issue?
> Problem is, I don't like to use `paxctl-ng -m /usr/bin/pidgin` because
> pidgin is one of "these" apps -
On 19 Sep 2015 at 17:45, Alex Efros wrote:
> > so try "readelf -edW /usr/lib64/opengl/nvidia/lib/libGLdispatch.so.0"
> > and post its output.
>
> Section Headers:
> [Nr] Name TypeAddress OffSize ES
> Flg Lk Inf Al
> [10] wtext PROGBITS
On 19 Sep 2015 at 20:24, Alex Efros wrote:
> On Sat, Sep 19, 2015 at 05:50:20PM +0200, PaX Team wrote:
> > so there're two things left to do:
> > 1. enable ELFRELOCS in your kernel config (and keep MPROTECT enforced
> >on all binaries)
>
> Done. This works. I
On 19 Sep 2015 at 22:40, Alex Efros wrote:
> Hi!
>
> On Sat, Sep 19, 2015 at 09:33:15PM +0200, PaX Team wrote:
> > > > 1. enable ELFRELOCS in your kernel config (and keep MPROTECT enforced
> > > >on all binaries)
> > > Done. This works. I don't
On 27 Sep 2015 at 10:44, "Tóth Attila" wrote:
> I've been seeing radeon related crashes upon boot on my laptop for a while
> now, but I could just recently capture this Oops, which can be related. If
> the machine hard-locks on boot, I can capture no messages. It looks, that
> most of the time it
On 28 Jan 2016 at 0:30, Alessandro Di Federico wrote:
> Hi, as you might know, global read-only data (e.g. the .rodata section)
> usually end up in the same segment as .text. This means that .rodata
> contains potentially executable data, which is always useful for an
> attacker looking for ROP ga
On 29 Jan 2016 at 16:44, Alessandro Di Federico wrote:
> On Thu, 28 Jan 2016 02:49:46 +0100
> "PaX Team" wrote:
>
> > because it's a useless security measure. for a non-executable .rodata
> > section to make any sense, the following condition would have to ho
On 29 Jan 2016 at 20:23, Alessandro Di Federico wrote:
> On Fri, 29 Jan 2016 18:13:23 +0100
> "PaX Team" wrote:
>
> > On 29 Jan 2016 at 16:44, Alessandro Di Federico wrote:
> >
> > > On Thu, 28 Jan 2016 02:49:46 +0100
> > > "PaX Team&qu
On 3 Mar 2016 at 17:44, ingo.schm...@binarysignals.net wrote:
> I'm still facing a bug with btrfs that
> occurs since 4.2.6-hardened-r6 till 4.4.2.
>
> An similar bug has been patched already
> https://patchwork.kernel.org/patch/7582351/
it doesn't look like it's the same bug (we've carried that
On 25 Oct 2016 at 19:35, wabe wrote:
> Interesting. I'm using hardened-sources-4.7.6 and qemu-2.7.0-r4 and
> don't have any problems so far. I'm using qemu VMs with xubuntu
> 14.04 and 16.04.
do you enable SANITIZE? 'cos that's what seems to trigger the problem for
Miroslav.
On 29 Apr 2017 at 16:11, Alex Efros wrote:
> Hi!
>
> On Sat, Apr 29, 2017 at 01:49:20PM +0200, Luis Ressel wrote:
> > in case anyone hasn't read in on LWN yet, here's what I'm talking
> > about: https://grsecurity.net/passing_the_baton.php
>
> Sorry for OT, but is this legal? Or, more correct, i
56 matches
Mail list logo
