3 Jan 2005 02:53
3 Jan 2005 20:19
Users visible on WHO list?
Hi All, We have protection enabled for users not to see each others processes (and this prevents them from being seen at all on "w") but who still shows them, and their IP. Any solution to this? D. -------------------------------- Dale Corse System Administrator Wolfpaw Services Inc. http://www.wolfpaw.net (780) 474-4095
3 Jan 2005 20:38
Re: Users visible on WHO list?
On Mon, Jan 03, 2005 at 12:19:05PM -0700, Wolfpaw - Dale Corse wrote: > Hi All, > > We have protection enabled for users not to see each others processes (and > this prevents them from being seen at all on "w") but who still shows them, > and their IP. 'w' uses /proc for its information while 'who' uses /var/run/utmp and ttys for its information. A possible solution is to make a utmp group, and have all binaries run as non-root that you want to allow to read /var/run/utmp to be sgid utmp. You can then chgrp utmp /var/run/utmp, chmod o-rwx /var/run/utmp, and either disable who, or modify its source so that it only displays information for their uid. Note that you can still see who is on the box by looking in /dev/pts. -Brad
_______________________________________________ grsecurity mailing list grsecurity@... http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
4 Jan 2005 01:01
Re: Text Relocations
> On Mon, Dec 13, 2004 at 03:35:14PM +0100, pageexec@... wrote: > > in general hunting down and fixing textrelocs requires some detective > > work and quite a bit of understanding of how the toolchain works. if you > > want to do it yourself, let me know and i'll try to dig up what i wrote > > to some gentoo hardened people a while ago. you should also enter this > > and other cases into the gentoo bugzilla so that the devs are aware of > > it. since some people asked off-list, so i dug it up finally: 1. readelf -l app -> note down the read-only PT_LOAD segment info, in particular VirtAddr and FileSiz, these provide the boundaries for the next step. 2. readelf -r app -> look for addresses under the Offset column that fall into the above determined range, not all types are interesting, only R_386_RELATIVE, R_386_32 and R_386_PC32 (all those are specific to i386 of course and i hope i didn't miss anything). 3. objdump -d app -> in the disassembly find the instructions around the addresses obtained in the previous step, on i386 they will never be the same exactly because a relocation falls into an instruction, e.g., if there's a reloc item on 0804c74c then in the disassembly you will find that the instruction that will be relocated is at 0804c74b or 0804c74a or something a few bytes lower. in any case, what matters is the function name in which this relocation is, you can just scroll up in the disasm and see which function appears first, that's the guy that wasn't compiled properly or has some issues (e.g., it comes from a .S file). of course you must have debug info for this to work, so have nostrip enabled.(Continue reading)
5 Jan 2005 16:57
Release candidate of grsecurity 2.1.0 for 2.4.28/2.6.10, please test
I've placed what will hopefully be the final released version of grsecurity 2.1.0 for 2.4.28 and 2.6.10 in http://grsecurity.net/~spender/ gradm 2.1.0 has also been uploaded there. Please test this as I plan to release within the next two days. -Brad
_______________________________________________ grsecurity mailing list grsecurity@... http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
4 Jan 2005 11:23
Debian, chpax and package upgrades
Hello I'm using Debian, and since I don't want to recompile libc etc. now (since I think (never tried) that's too complicated to handle for a larger number of (virtual root-)hosts from which many aren't administrated by me)), I'm still using chpax. This is working fine, but it is tedious to chpax binaries again if packages are being upgraded (and explaining the other admins how to do it is tedious as well). So I'd like to have a scheme where after a package upgrade, some callback script is run (either only for packages in some local list of pax-sensitive packages, or for all packages but with an argument mentioning the package name). Any ideas? (or tips where to ask?) Thanks Christian.
5 Jan 2005 17:50
Re: Debian, chpax and package upgrades
Christian Jaeger <christian.jaeger@...> wrote: > I'm using Debian, and since I don't want to recompile libc etc. now > (since I think (never tried) that's too complicated to handle for a > larger number of (virtual root-)hosts from which many aren't > administrated by me)), I'm still using chpax. This is working fine, > but it is tedious to chpax binaries again if packages are being > upgraded (and explaining the other admins how to do it is tedious as > well). So I'd like to have a scheme where after a package upgrade, > some callback script is run (either only for packages in some local > list of pax-sensitive packages, or for all packages but with an > argument mentioning the package name). > > Any ideas? (or tips where to ask?) Gentoo has an "init" script called "chpax" that doesn't really initialize anything, it just sets PaX flags using either or both of chpax or paxctl for programs that need it. You could do something like that for Debian. (An actual Gentoo init script wouldn't be compatible with Debian.) It doesn't actually have to be an init script. The basic idea is to put all your PaX flag changes in a script you can just run. It changes all settings throughout the system, but that doesn't take too long. -- -- Barry.Schwartz@... http://www.chemoelectric.org "I have directed that in the future I sign each letter." -- Rumsfeld
(Continue reading)
5 Jan 2005 20:07
Re: Debian, chpax and package upgrades
> So I'd like to have a scheme where after a package upgrade,
> some callback script is run (either only for packages in some local
> list of pax-sensitive packages, or for all packages but with an
> argument mentioning the package name).
>
> Any ideas? (or tips where to ask?)
how about chpax.{sh,cfg} on the PaX site?
5 Jan 2005 19:58
Re: Release candidate of grsecurity 2.1.0 for 2.4.28/2.6.10, please test
Brad Spengler (spender@...) wrote on 5 January 2005 10:57: >I've placed what will hopefully be the final released version of >grsecurity 2.1.0 for 2.4.28 and 2.6.10 in http://grsecurity.net/~spender/ >gradm 2.1.0 has also been uploaded there. Please test this as I plan to >release within the next two days. Could you please clarify the meaning and order of the patches? This is too important for me to go by trial and error... If I understand the patch is for 2.4.28 and not 2.4.29-pre3. There's also linux-2.4.28-secfixes.patch. Is this the fixes that are included in the transition from 2.4.28 to 2.4.29-pre3? Something else or less? Is it already included in grsecurity-2.1.0-2.4.28-200501051112.patch? If not in which order should they be applied? Sorry for the bother...
5 Jan 2005 20:16
Re: Release candidate of grsecurity 2.1.0 for 2.4.28/2.6.10, please test
> Could you please clarify the meaning and order of the patches? This is > too important for me to go by trial and error... If I understand the > patch is for 2.4.28 and not 2.4.29-pre3. There's also > linux-2.4.28-secfixes.patch. Is this the fixes that are included in > the transition from 2.4.28 to 2.4.29-pre3? Something else or less? > Is it already included in > grsecurity-2.1.0-2.4.28-200501051112.patch? If not in which order > should they be applied? The grsecurity patch should be applied first, then the 2.4.28 secfix patch (if you're patching 2.4.28). The secfix patch includes all the fixes applied to the grsec-sources kernel package of gentoo, along with some other fixes. You can view a listing of the fixes in the grsec-sources tree at: http://gentoo.kems.net/gentoo-x86-portage/sys-kernel/grsec-sources/files/ and the other fixes at: http://www.exinferis.de/linux/kernel/security/2.4.28/ I've uploaded a new secfix patch that has the date in the filename. -Brad
_______________________________________________ grsecurity mailing list grsecurity@... http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
RSS Feed