gmane.linux.kernel.grsecurity

Re: The terminal you are using is unsafe for this operation. Use another terminal.

Brad Spengler — 2013-05-15T13:15:45

This is caused by another process having your terminal open, allowing
it to potentially steal keystrokes.  The culprit should be reported
in your dmesg ("terminal being sniffed by...") or can be found via lsof.
In the past there have been problems with init scripts passing on terminal
file descriptors to started services:
http://forums.grsecurity.net/viewtopic.php?f=5&t=1081

-Brad

On Wed, May 15, 2013 at 08:37:45PM +0800, channe wrote:
_______________________________________________
grsecurity mailing list
grsecurity-JNS0hek0TMl4qEwOxq4T+Q< at >public.gmane.org
http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity

The terminal you are using is unsafe for this operation. Use another terminal.

channe — 2013-05-15T12:37:45

Hi~

I'm a fresh man to grsec.

Today I met a strange probelm, when I try to run "gradm -a admin", I 
was told "The terminal you are using is unsafe for this operation.  Use 
another terminal."

the username I was using is root.
and the policy usr is default which has G flag



Has anyone met this problem ? Thanks.

Feature suggestion

azurIt — 2012-12-19T18:26:57

Hi,

we are having little problems with symlinks and security (well, these two things were always doing problems when needed togater). One example can be seen here:
https://forums.proftpd.org/smf/index.php?topic=11225.new

To make things short - we would like to deny creating of symlinks to our users. Not all applications can disallow this so it would be best to make it on kernel level. What about to make a feature in grsecurity which will work similar to TPE? Create a group which is able/not able to _create_ symlinks. What do you think?

azur

Message explanation

azurIt — 2012-12-10T10:19:58

Hi,

can anyone, please, explain this message? Never saw it until yesterday, no luck with Google.

Dec 10 02:03:29 server01 kernel: [  220.366486] grsec: From 141.105.120.152: bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds.  Please investigate the crash report for /usr/lib/apache2/mpm-itk/apache2[apache2:3586] uid/euid:1258/1258 gid/egid:100/100, parent /usr/lib/apache2/mpm-itk/apache2[apache2:2142] uid/euid:0/0 gid/egid:0/0

Thank you!

azurIt

how to check the hardware support of XN/XI bit support onARM/MIPS platform

Girish garg — 2013-01-03T09:46:24

Hi All,

Please let me know how to check the hardware support of XN/XI bit support
on ARM/MIPS platform.

As there is support of XN bit on ARM v >= 6 (I was using ARM 6), but no
support on MIPS (*MIPS 34Kc)*.

To check the hardware support , I run the paxtest i.e execstack. The
execstack test program must crash on ARM, but not on MIPS.

*But It is crashing on both ARM and MIPS.*

Please let me know how I can prove/check the hardware support of XN bit in
arm platform.



/* *execstack.c* - Tests wether code on the stack can be executed

 *

*/

#include <stdlib.h>

#include <stdio.h>

#include <sys/mman.h>

#include <unistd.h>

#include <errno.h>

#include <limits.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/wait.h>



#ifndef PAGESIZE

#define PAGESIZE        (4096)

#endif /* PAGESIZE */



typedef void (*fptr)(void);

char *testname = "Executable stack                         ";



void itworked( void )

{

        printf( "Vulnerable\n" );

        exit( 1 );

}



void doit( void )

{

Re: a new plugin: size_overflow

PaX Team — 2012-08-29T13:53:52


as those on the rss feed have no doubt noticed it by now, her blog post's been
out since last night:

   http://forums.grsecurity.net/viewtopic.php?f=7&t=3043

enjoy ;)

new gcc plugin: latent entropy extraction

PaX Team — 2012-07-23T20:11:37

hello everyone,

it's time to introduce the newest member of our plugin family to you. the
inspiration came from the work described at https://factorable.net/ that
you should all check out eventually (and do get your keys tested).

the short story is that generating crypto keys while the system's random
pool is low on entropy is not a good idea. and it so happens that some
systems do actually have little entropy after boot when some userland
decides to generate said keys. the end result is not pretty, the details
are in the paper at the above URL.

now there are several ways to improve the situation, some will soon find
their way into the kernel in fact (check out the random tree by Theodore
Ts'o at http://git.kernel.org/?p=linux/kernel/git/tytso/random.git;a=summary).

the basic idea is always to find some potential source of randomness, or
even just deterministic diversity (e.g., a MAC address) and mix that into
the random pools in the hope that enough bits accumulate by the time some
early userland app de

Re: 64bit Debian, Java 1.7 64bit and Bukkit

Daniel Schulz — 2012-05-10T10:37:16

"PaX Team" <pageexec-Y8qEzhMunLyT9ig0jae3mg< at >public.gmane.org> schrieb:

you're right. i disabled PAX_EI_PAX, now:

root< at >server:~# cat /proc/1383/status
[...]
PaX:    pemrs


Yes, same way with 2.6.32.59.


I have compiled a 3.2.16 with grsec now and the bukkit-server starts without 
any problems. great.

Thank you very very much again! :-)

Daniel

Re: 64bit Debian, Java 1.7 64bit and Bukkit

PaX Team — 2012-05-09T19:52:24


vs.


first, paxctl flags have no effect on your binary, so you should figure out how
you configured the PaX control method ;).

second, can you compile/run this small program:

------------------------------------------------------------------------------------------
#include <stdio.h>
#include <sys/mman.h>
int main(void)
{
        return (long)mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0);
}
------------------------------------------------------------------------------------------

and see if it fails the same way? and if it does, can you try it on a more recent
kernel, say 3.3.5? i have the latter here and it worked fine, so maybe it's a problem
specific to 2.6.32 but before i make my system bootable with 2.6.32 again (hello udev),
i'd like to know for sure.

also, is there anything in dmesg or on the console when the system hangs (maybe try
netconsole)?

64bit Debian, Java 1.7 64bit and Bukkit

Daniel Schulz — 2012-05-09T10:24:34

Hello,

i have install Debian Squeeze 64bit, grsecurity-2.9-2.6.32.59-201204272005.patch 
and a original jre 64bit from java.com. Now i try to run my bukkit/minecraft-Server 
but everytime i start it, the complete server stuck, i can just reset him,
"reboot" no longer works. With the standard Debian Kernel, everything
works fine. 

Some Infos:


root< at >server:/usr/local/jre1.7.0_04/bin# paxctl -v java
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team <pageexec-Y8qEzhMunLyT9ig0jae3mg< at >public.gmane.org>

- PaX flags: -p-s-m-x-e-r [java]
        PAGEEXEC is disabled
        SEGMEXEC is disabled
        MPROTECT is disabled
        RANDEXEC is disabled
        EMUTRAMP is disabled
        RANDMMAP is disabled
root< at >server:/usr/local/jre1.7.0_04/bin# uname -a
Linux example.org 2.6.32.59-grsec #5 SMP Fri May 4 13:11:45 UTC 2012 x86_64 GNU/Linux
 
root< at >server:/home/mc/bukkit-server# ps ax|grep java
 1411 pts/2    S+     0:00 strace -f /usr/local/jre1.7.0_04/bin/java -Xincgc -Xmx1G -Djava.awt.headless=true -jar cr

a new plugin: size_overflow

PaX Team — 2012-03-17T12:15:35

hello folks,

as of last night we have a new plugin from Emese Revfy (author of the constify
plugin as well) that i'd like to briefly introduce to you now (while she's working
on her blog post ;).

first some background: almost 3 years ago we had introduced a small hack into
grsecurity to handle a specific bug class, namely, (unintended) integer overflows
occuring in calculating certain function parameters, such as those used to
allocate memory or copy data between the kernel and userland (the bug class is
obviously not specific to the kernel, userland programs have had their fair
share of them over the years ;). the effect of such bugs is that due to the
finite precision of integers, the integer overflow ends up producing a value
much smaller than the program logic assumes. this in turn can cause memory
underallocation and a buffer overflow on later accesses, among others.

spender's hack attempted to handle a specific but also quite typical instance
of these bugs where the calculation is a simple multiplic

Re: grsecurity and a minecraft-plugin (java)

2011-12-02T12:05:02

it's because the jvm runs out of address space randomly (due to ASLR the
biggest address space hole size changes randomly, so sometimes this failing
allocation does succeed). now i don't quite see why the address space is
consumed so much based on the strace but i did note that you should be using
PAGEEXEC since your CPU is capable of NX support (you'll also have to enable
PAE in .config).

Re: grsecurity and a minecraft-plugin (java)

2011-11-30T14:37:21


you'd have to strace -f the server process(es) and send us the logs, we have to
see what syscall is failing. also, what is your kernel .config and /proc/cpuinfo
(in particular i'm wondering if you're using SEGMEXEC or PAGEEXEC, you can check
it in /proc/<pid>/status for a given process)?

grsecurity and a minecraft-plugin (java)

Daniel Schulz — 2011-11-30T14:35:10

Hi there,

first of all, thanks very much for grsecurity. Its a very useful and
easy to use kernel-hardening-patch. 

I have successfully compile a kernel 2.6.32.49-grsec on Debian Squeeze
32bit, first with "Security Level high". Because, a java Server does not
start with enabled mprotect, i have disable this option (and change
"Security Level to Custom). Now, the Minecraft-Server starts, but something 
is not right yet:

-------------------------------------------------------------
[...]
14:55:51 [SCHWERWIEGEND] Error occurred while enabling dynmap v0.24 (Is it up to date?): unable to create new native thread
java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Thread.java:640)
        at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:703)
        at java.util.concurrent.ThreadPoolExecutor.prestartCoreThread(ThreadPoolExecutor.java:1381)
        at java.util.concurrent.Schedu

TCP Timestamp Randomization

Florian Weingarten — 2011-11-24T13:52:12

Hi list,

I am currently working on methods to detect (identify, count, filter)
single hosts behind NAT gateways. We already have a working proof of
concept which uses TCP timestamps (the basic idea is similar to the one
introduced in Phrack a few years ago). A trivial way to defeat this
approach (without deactivating timestamps) is to randomize initial
timestamp values on a per-connection basis (instead of initializing it
to the current system time, like Linux does).

OpenBSD already has this feature ("reassamble tcp"). Is something like
this implemented (or planned to be implemented) in grsecurity? If not, why?

Thanks!

Flo

Re: Cracking attempt?

2011-11-15T15:33:18


it's hard to say without a coredump, it looks more like a 'normal' bug to me. on the other hand it
looks like i should treat 32 bit processes under a 64 bit kernel as such when dumping the stack ;).

Cracking attempt?

Marc Schiffbauer — 2011-11-15T15:45:04

Hi all,

last night i discovered following logs on one of my servers.

What do you think, is this a cracking attempt?

Nov 15 02:24:39 vesta kernel: PAX: execution attempt in: (null), 00000000-00000000 00000000
Nov 15 02:24:39 vesta kernel: PAX: terminating task: /usr/bin/php5-cgi(php5-cgi):11354, uid/euid: 1022/1022, PC: 00000000e8e487b0, SP: 00000000f492617c
Nov 15 02:24:39 vesta kernel: PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
Nov 15 02:24:39 vesta kernel: PAX: bytes at SP-8: e9b71538e97b4f8c 00000009e97ecf85 e98d82ff00000001 f49261d000000161 0859d850e9ebc87b e98d82ffe98e8124 f49261c808552b60 00000009e985ce3d e98d82ff00000001 e98e812400000161 f49261e80859ff00
Nov 15 02:24:39 vesta kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /srv/chroots/www/usr/bin/php5-cgi[php5-cgi:11354] uid/euid:1022/1022 gid/egid:103/103, parent /srv/chroots/www/usr/bin/php5-cgi[php5-cgi:11348] uid/euid:1022/1022 gid/egid:103/103

This happened 9 t

Upcoming sponsorship opportunity

Brad Spengler — 2011-06-29T00:52:58

Hi all,

I wanted to let you know about an opportunity within the next month or
two that you may be interested in.  Due to some unique real-life
events, in a month or two I'll have at least a month of mostly free
time.  I figured it'd be a good idea to put the downtime to good use:
knocking  out large items on my TODO list that I don't currently have
time to dedicate to in my free time apart from the normal maintenance,
development, and support of grsecurity.

If I can find some new sponsors at least for the stretch of my time off,
I'll tackle some things like:
Allowing /proc restrictions to be toggled via sysctl at runtime
More documentation
Container support for RBAC/chroot restrictions
 - there are some options here (for RBAC): making RBAC policies act as a
   global policy that applies to all containers, requiring per-namespace
   policies, or having a global RBAC policy that can be overriden
   by per-namespace policies (with some subset of privilege checks)
IPv6 support for RBAC socket policies
Runtime

Re: a couple of questions about grsec policiesforTahoe-LAFS

Brad Spengler — 2011-06-17T11:59:21

These aren't bugs :) For the first issue, it's a matter of reading the 
configuration help for the options that were enabled.  In this case, 
CONFIG_GRKERNSEC_PROC_USERGROUP is enabled by grsec on the 'high' 
setting.  This denies non-root users from viewing /proc/net, *except* 
for those in a special GID (1001 by default, which I imagine wasn't 
changed).  That gid should have been visible when listing /proc.  One 
solution is to require users needing to run this to be assigned to the 
special group.

For the second issue, it's likely due to fallout from the first -- the 
application tried to coredump, but was unable to.  This wasn't due to 
grsecurity, but rather due to your existing resource limits.  grsecurity 
in this case is only logging the event.

-Brad
_______________________________________________
grsecurity mailing list
grsecurity-JNS0hek0TMl4qEwOxq4T+Q< at >public.gmane.org
http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity

a couple of questions about grsec policies for Tahoe-LAFS

Zooko O'Whielacronx — 2011-06-17T05:19:40

Dear grsecurity folks:

I'm a developer on Tahoe-LAFS, a secure and fault-tolerant cloud storage system:

http://tahoe-lafs.org

I've recently gotten more interested in having a hardened operating
system under Tahoe-LAFS deployments.

Jacob Appelbaum ran Tahoe-LAFS on grsec and reported two problems. If
you could please have a look at these two issues and let us Tahoe-LAFS
developers know how grsec thinks about such things I would appreciate
it:

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/982# grsec disallows
tahoe from learning its own IP address
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1421# increase_rlimits()
tries to set RLIMIT_CORE high, which grsec disallows

Thanks!

If you go ahead and register on the Tahoe-LAFS trac in order to update
the ticket, that will be the best way to communicate with the
Tahoe-LAFS developers (who are far more than just me), but if you
don't want to register and you just reply to this message then I'll
cut and paste your reply into those tickets.

Regards,

Zooko

Patch for CONFIG_NET=n

Robert Beeporbop — 2011-05-24T07:20:39

I patched linux 2.6.38.6 with the grsecurity patch, and then configured the kernel with no networking support. Below is a patch to make that work... I have also attempted to patch the kernel with both the grsecurity patch and the xen dom0 patch (from http://code.google.com/p/gentoo-xen-kernel/downloads/list), there are some problems... If anyone has a patch for this, please forward it on! I have started merging, so if this isn't already done, I will have a patch for this eventually. I am moving to 2.6.39, and there are a few problems with the xen dom0 patch as well.

After this, I am going to reduce the Linux kernel down to the bare minimum, whacking entire kernel subsystems if possible, to make a hardened xen dom0 "monitor". And, implement some in-kernel framebuffer mirroring routines so that networking is not necessary to access domU framebuffers locally. If anyone has any interest in this, or has done any related work, please tell me! I'm going to work on it anyways, though I'll probably go faster if othe