Fwd: Re: Bug#336461: debhelper: dh_fixperms - xargs: chown: Argument list too long

Hi,

is this a supposed behaviour in grsec? And if yes, is it possible to make  
(getconf ARG_MAX)-(printenv | wc -m) a reliable number again?

Please let me know if you need more info,

thanks,

Bernd

----------  Forwarded Message  ----------

Subject: Re: Bug#336461: debhelper: dh_fixperms - xargs: chown: Argument list 
too long
Date: Saturday 05 November 2005 16:01
From: Andreas Metzler <ametzler@...>
To: Bernd Zeimetz <bernd@...>, 336461@...

On 2005-10-30 Bernd Zeimetz <bernd@...> wrote:
> > Is this repeatable? i.e. could you show me something like
> > 1 do this
> > 2 do that
> > 3 same error occurs everytime
>
> sure.

[...]

Re: Fwd: Re: Bug#336461: debhelper: dh_fixperms - xargs: chown: Argument list too long

On 8 Nov 2005 at 19:04, Bernd Zeimetz wrote:
> is this a supposed behaviour in grsec? And if yes, is it possible to make  
> (getconf ARG_MAX)-(printenv | wc -m) a reliable number again?

it is a reliable number (as in, it's a constant) but its use is
based on the assumption that it reflects the actually usable space
on the initial userland stack. due to the stack randomization that
PaX does, this assumption is no longer valid as there's an up to
PAGE_SIZE large random padding at the bottom of the stack that is
not accounted for in the environment. i thought of a quick workaround,
i'd appreciate if you gave it a try (patch might be whitespace damaged):

--- linux-2.6.14-pax/include/linux/binfmts.h    2005-10-28 12:07:46.000000000 +0200
+++ linux-2.6.14-pax/include/linux/binfmts.h    2005-11-09 00:49:42.000000000 +0100
 <at>  <at>  -7,10 +7,10  <at>  <at> 

 /*
  * MAX_ARG_PAGES defines the number of pages allocated for arguments
- * and envelope for the new program. 32 should suffice, this gives
- * a maximum env+arg of 128kB w/4KB pages!
+ * and envelope for the new program. 33 should suffice, this gives
+ * a maximum env+arg of 132kB w/4KB pages!
  */
-#define MAX_ARG_PAGES 32
+#define MAX_ARG_PAGES 33

 /* sizeof(linux_binprm->buf) */
 #define BINPRM_BUF_SIZE 128

Re: Fwd: Re: Bug#336461: debhelper: dh_fixperms - xargs: chown: Argument list too long

Hi.

> not accounted for in the environment. i thought of a quick workaround,
> i'd appreciate if you gave it a try (patch might be whitespace damaged):

I've applied the patch - here're the results:

> Please note two things:
> * There is a huge gap of more than 4KB between
>  (getconf ARG_MAX)-(printenv | wc -m) (equals 129968) and the really
>  usable number of arguments (about 125860).

this looks much better now. xargs works again in the case I had the problem 
with it originally.
From the source of xargs:

  /* IEE Std 1003.1, 2003 specifies that the combined argument and
   * environment list shall not exceed {ARG_MAX}-2048 bytes.  It also
   * specifies that it shall be at least LINE_MAX.
   */

and they take care of that rule. So I think your workaround should fix it, or 
did I calc something wrong!?

back to the test program from Andres Metzler - 
one:/tmp# echo $((`getconf ARG_MAX`-`printenv | wc -m`))
130124

for $((`getconf ARG_MAX`-`printenv | wc -m` -15 )) it seems to work reliable 
now.

Re: Fwd: Re: Bug#336461: debhelper: dh_fixperms - xargs: chown: Argument list too long

On 9 Nov 2005 at 3:49, Bernd Zeimetz wrote:
> this looks much better now. xargs works again in the case I had the problem 
> with it originally.
> From the source of xargs:
> 
>   /* IEE Std 1003.1, 2003 specifies that the combined argument and
>    * environment list shall not exceed {ARG_MAX}-2048 bytes.  It also
>    * specifies that it shall be at least LINE_MAX.
>    */
> 
> and they take care of that rule.

interesting, where exactly does that quote come from? in my copy of
the spec i can find only this:

9565 The number of bytes available for the new process’ combined argument and environment lists is
9566 {ARG_MAX}. It is implementation-defined whether null terminators, pointers, and/or any
9567 alignment bytes are included in this total.

and

28305 The number of bytes available for the child process’ combined argument and environment lists
28306 is {ARG_MAX}. The implementation shall specify in the system documentation (see the Base
28307 Definitions volume of IEEE Std 1003.1-2001, Chapter 2, Conformance) whether any list
28308 overhead, such as length words, null terminators, pointers, or alignment bytes, is included in
28309 this total.

note 'any alignment bytes'. now i don't know how 'alignment' is defined
in this context (in PaX it'd be up to PAGE_SIZE), but at least it means
that userland can't really assume a constant/fixed amount of actually

Re: Fwd: Re: Bug#336461: debhelper: dh_fixperms - xargs: chown: Argument list too long

 <pageexec <at> ...> writes:
> On 9 Nov 2005 at 3:49, Bernd Zeimetz wrote:
[...]
> > From the source of xargs:
> >   /* IEE Std 1003.1, 2003 specifies that the combined argument and
> >    * environment list shall not exceed {ARG_MAX}-2048 bytes.  It also
> >    * specifies that it shall be at least LINE_MAX.
> >    */
[...] 
> interesting, where exactly does that quote come from?
[...]

Hello,
It is part of the xargs-specific chapter in Shell and Utilities volume (XCU).
The rationale says:

| The requirement that xargs never produces command lines such that
| invocation of utility is within 2048 bytes of hitting the POSIX exec
| {ARG_MAX} limitations is intended to guarantee that the invoked utility
| has room to modify its environment variables and command line arguments
| and still be able to invoke another utility. [...]

            hth, cu andreas

grsecurity 2.1.7 released for Linux 2.4.32-rc3/2.6.14.2

grsecurity 2.1.7 has been released for the 2.4.32-rc3 and 2.6.14.2 
versions of the Linux kernel. Changes in this version include:

    * The internal storing and searching of objects, subjects, and roles 
      in the RBAC system has been overhauled. We now use chained hash tables 
      that offer much better long-run performance. The IP tagging code also 
      benefits from this change, which should improve overall system
      performance.
    * Processes are now allowed to read their own /proc/≤pid>/maps file, 
      fixing a compatibility issue with libpthread
    * Many PaX updates, including a fix that corrects xargs behavior 
      with long argument lists
    * Learning config update: /tmp, /var/tmp will always reduce
    * CPU time resource limits in the RBAC system have been corrected
    * Only /dev/urandom is now used for generating the salt for the 
      password hashes, correct the gradm -P users with low entropy for 
      randomness experienced. /dev/urandom is safe to use in this case, since 
      the salt we are generating is large compared to normal password hashing 
      routines, and the hash itself is kept secret while the RBAC system is 
      enabled.
    * Usernames with "." in them are now supported in RBAC policy
    * Fixed problem in RBAC system where keventd would be denied a 
      signal send to X11
    * Fixed a problem with alarm() and the chroot restrictions
    * Several other bugfixes

-Brad

_______________________________________________

module support under KERNEXEC

the latest PaX test patch for 2.6 adds preliminary module support
under KERNEXEC, that is, you can now have non-executable pages and
keep using modules. of course as it is now, it's a complete circumvention
of the very idea of KERNEXEC (disabling runtime code generation in
the kernel itself), but we'll get to that later.

for now i'd like to ask adventurous souls to enable KERNEXEC and
module support and see what blows up. it works here (TM), but that's
a small sample, hence my request. if your life depends on your machine
then better wait (it doesn't go into grsec either for some time).
if something does blow up, then be prepared to have a serial console
attached (or maybe netconsole) and logging enabled, else your kernel
will most likely be dead (or just reboot), and taking a screenshot
by hand is not much fun ;P.

some things to be aware of:
 - KERNEXEC is not compatible with EFI, HOTPLUG_PCI_COMPAQ_NVRAM
   and PCI_BIOS support. the latter is easy to fix as you just have
   to set the PCI access method to direct. the former two depend
   on your hardware, probably most of you are not affected.

 - linux in a vmware guest works fine, so you can test there (although
   i tried that myself, so it's not really a new data point). linux
   (with KERNEXEC enabled) as a vmware host will most likely not work,
   but i didn't try that myself. if it does, then it's still bad news
   as it means that it probably circumvents KERNEXEC .

 - due to the way non-executable pages can be implemented on i386,
   the non-writable (that is, executable code and read-only data)
   region reserved for modules is limited and has to be a compile

Compileerror 2.4.32 fs/proc/array.c

Hi,
this morning i got am error while compiling grsec:

array.c: In function `proc_pid_stat':
array.c:371: structure has no member named `pax_flags'
array.c:371: structure has no member named `pax_flags'
array.c:423: structure has no member named `pax_flags'
array.c:423: structure has no member named `pax_flags'
array.c:424: structure has no member named `pax_flags'
array.c:424: structure has no member named `pax_flags'
array.c:425: structure has no member named `pax_flags'
array.c:425: structure has no member named `pax_flags'
array.c: In function `show_map':
array.c:583: structure has no member named `pax_flags'
array.c:583: structure has no member named `pax_flags'
array.c:584: structure has no member named `pax_flags'
array.c:584: structure has no member named `pax_flags'
array.c:594: structure has no member named `pax_flags'
array.c:594: structure has no member named `pax_flags'
make[3]: *** [array.o] Fehler 1
make[3]: Verlassen des Verzeichnisses Verzeichnis
>/entwicklungen/kernels/linux-2.4.32/fs/proc<
make[2]: *** [first_rule] Fehler 2
make[2]: Verlassen des Verzeichnisses Verzeichnis
>/entwicklungen/kernels/linux-2.4.32/fs/proc<
make[1]: *** [_subdir_proc] Fehler 2
make[1]: Verlassen des Verzeichnisses Verzeichnis
>/entwicklungen/kernels/linux-2.4.32/fs<

After Reading Quick Start...then what?

Hey guys,
	Im new to grsec but not new to the idea of MAC's. I was a LIDS user for a few years but when I read an article
on linuxsecurity.com about the new grsec i decided to check it out. Ive downloaded, installed, patched and rebooted
my new 2.6.14.2 grsec kernel. I chose the "custom" option and read through and implemented the options from the
quick start guide. 

	I then put the system into full learning mode and let it run for a few days, careful not to do anything
thta would require root access.
	
	When I enable (-E) the ststem, and check my logs, I notice that klogd needs CAP_SYS_ADMIN to read/write to 
/proc, im sure there are other errors, which will be taken care as they show up, but my question is what files 
do I edit to tweak the policy to remove errors such as the one listed above?

	The quick start quide is great, but then the user is left on his own at that point. Why not add to the quick 
start guide (or write a new guide) that starts off just after you haev rebooted and enabled the system.

	An explination of the policy synthax etc would help as well. I haev checked out /etc/grsec/
and there indeed is a file called "policy" but how to we tweak the policy? or add new rules? or remove rules?
what if we install a new daemon and it needs to do something that requires more privlidges then the current
policy 
allows? how do we go about changing it?

	thanks for reading guys, appreciate any and all comments

	P.S - im REALLY liking grsecurity and I will be using this sytem now was my MAC of choice. So thanks GRSEC, 
perhaps now i can sleep at nite lol

--

-- 
Kurt Pomeroy
Systems Administrator / IT Technician

Re: grsecurity Digest, Vol 17, Issue 6

Hi Kurt,

    I just finished my course conclusion work on Grsecurity and Lids.
After you reboot your brand new system, you should put it to learn.

    In this mode, grsec will learn the way each application works and
create a new policy file

Learning:

244 gradm -F -L /etc/grsec/learning.logs	# start learning.
245 cd /etc/cron.daily/		# Crontab commands
246 ls –l			# Crontab commands
249 ./find			# Crontab commands
250 ./logrotate		# Crontab commands
...
281 gradm –D		# Finish learning.

Creating the new policy:

grsec:/home/sysadm# mv /etc/grsec/policy /etc/grsec/policy.old
grsec:/home/sysadm# gradm -F -L ./learning.logs -O /etc/grsec/policy
Beginning full learning 1st pass...done.
Beginning full learning role reduction...done.
Beginning full learning 2nd pass...done.
Beginning full learning subject reduction for user root...done.
Beginning full learning subject reduction for user postfix...done.
...
Beginning full learning object reduction for subject /...done.
Beginning full learning object reduction for subject /usr/bin/mutt...done.