init scripts and su
The start scripts for some daemons do "su - user" or use
"start-stop-daemon -c" to launch the daemon, postgresql is one example.
During the time between the daemon launch and it closing it's file handles and
calling setsid(2) (which some daemons don't do because they are buggy) any
other code running in the same UID could take over the process via ptrace,
fork off a child process that inherits the administrator tty, and then stuff
characters into the keyboard buffer with ioctl(fd,TIOCSTI,&c) (*).
To address these issues for Fedora I have written a program named init_su.
init_su closes all file handles other than 1 and 2 (stdout and stderr). File
handles 1 and 2 are fstat()'d, if they are regular files or pipes then they
are left open (no attack is possible through a file or pipe), otherwise they
are closed and /dev/null is opened instead. /dev/null is opened for file
handle 0 regardless of what it might have pointed to previously. Then
setsid() is called to create a new session for the process (make it a group
leader), this invalidates /dev/tty. Then the uid is changed and the daemon
is started.
I have attached the source code to init_su, please check it out and tell me
what you think. After the discussion concludes I will write a patch for
start-stop-daemon to give similar functionality.
(*) On system boot and shutdown there is no problem. It's when the
administrator uses /etc/init.d/postgresql to start or stop the database that
there is potential for attack.
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01314.html
I have also started a similar discussion on the Fedora development list about
this issue, see the above URL.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
#include
#include
#include
#include
#include
#include
#include
#include
#include
void usage(const char * const msg)
{
if(msg)
fprintf(stderr, "Error: %s\n\n", msg);
fprintf(stderr, "Usage: init_su [-l] user -c command\n");
exit(1);
}
int main(int argc, char **argv)
{
int i, fd;
int login = 0;
char *command = NULL, *user = NULL, *shell = NULL, *nu_argv[4];
struct passwd *pw;
int int_c = 0;
while(int_c != -1)
{
int_c = getopt(argc, argv, "-lc:s:");
switch(int_c)
{
case 1:
if(!strcmp(optarg, "-"))
{
login = 1;
}
else
{
user = optarg;
}
break;
case 'l':
login = 1;
break;
case 's':
shell = optarg;
break;
case 'c':
command = optarg;
break;
}
}
if(!user || !command)
usage(NULL);
pw = getpwnam(user);
if(!pw)
usage("User unknown.");
if(setregid(pw->pw_gid, pw->pw_gid))
usage("Can't setgid(), are you root?");
if(setreuid(pw->pw_uid, pw->pw_uid))
usage("Can't setuid(), are you root?");
if(!shell)
shell = pw->pw_shell;
if(login)
{
nu_argv[0] = strrchr(shell, '/');
if(!nu_argv[0])
usage("Bad shell.");
nu_argv[0] = strdup(nu_argv[0]);
nu_argv[0][0] = '-';
}
else
nu_argv[0] = shell;
nu_argv[1] = "-c";
nu_argv[2] = command;
nu_argv[3] = NULL;
close(0);
for(i = 3; i < 1024; i++)
close(i);
openlog("initrc_su", LOG_CONS | LOG_NOWAIT, LOG_DAEMON);
fd = open("/dev/null", O_RDWR);
if(fd == -1)
{
syslog(LOG_ERR, "Can't open /dev/null when trying to execute program %s", command);
return 1;
}
for(i = 0; i < 3; i++)
{
struct stat sbuf;
if(i != fd && (fstat(i, &sbuf) == -1 || (!S_ISREG(sbuf.st_mode) && !S_ISFIFO(sbuf.st_mode)) ))
{
close(i);
if(dup2(fd, i) != i)
{
syslog(LOG_ERR, "Can't dup2() when trying to execute program %s", command);
return 1;
}
}
}
if(fd >= 3)
close(fd);
setsid(); /* it's OK if this fails as we get the right result anyway */
execv(shell, nu_argv);
syslog(LOG_ERR, "Can't exec program %s", command);
return 1;
}
Re: PaX on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Found a problem. Russell Coker wrote: | On Mon, 26 Jul 2004 02:57, John Richard Moser <[EMAIL PROTECTED]> wrote: [...] | | We have recently discussed this on at least one of the lists you posted to. | The end result of the discussion is that GCC is getting another SSP type | technology known as "mudflap". Mudflap depends on some major new features of | GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the | Debian GCC people don't want to merge in other patches which have no apparent | chance of being included upstream. | - cut | Upstream has already decided to support mudflap in GCC 3.5, which is | even more far-reaching than SSP. I'm not sure whether all users of SSP would he happy with mudflap as a replacement. It has a different focus; it was designed as debugging tool. For example it probably incurs a much larger performance overhead, since basically every pointer dereference goes through a hash table. - cut http://lists.debian.org/debian-devel/2004/07/msg01154.html It's a high-overhead debugging tool? I can understand this: The GCC team would be more concerned with helping you FIX security issues than blocking them at exploit time. It shouldn't interfere with ProPolice anyway, I've been told, so you may want to go with SSP/ProPolice for security reasons. Either way, moving to mudflap is going to require a full system recompile on your end, so what do you really lose? :) - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitely stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBIvNhDd4aOud5P8RAlZKAKCIQ1bhrB6NkQMl36TBBXMD8ypyjwCfVhC8 +HS4a3waTxdgclEdfsmGPqc= =la0p -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russell Coker wrote: | On Mon, 26 Jul 2004 13:48, John Richard Moser <[EMAIL PROTECTED]> wrote: | |>| Before we can even start thinking about PaX on Debian we need to find a |>| maintainer for the kernel patch who will package new versions of the |>| patch which apply to the Debian kernel source tree. We have had a few |> |>Are you talking PaX or grsecurity? PaX is significantly less invasive |>than grsecurity. There will still be issues, of course. | | | PaX. AFAIK the only PaX kernel-patch package in Debian is the Adamantix | kernel source, which has RSBAC and a bunch of other stuff, and the GRSec | patch. Neither of them apply to the Debian kernel source tree. | | I'm pretty much proposing that all your sources include PaX; your binaries can have it compiled out. I've got a working PaX patch for 2.6.7-ck* :) It was only a 1 miss issue. I'll see if Deb sources are kind or if they rape my ass. . . |>Where would I see debian's 2.6.7 source tree? I'm not a deb user, |>remember, so I'll need a tarball or something. | | | http://ftp.debian.org/debian/pool/main/k/ | OK how the hell does this work? What's this supposed to apply to? kernel-source-2.6.7_2.6.7-3_all.deb ? ahh, 2.6.7 + kernel-source-2.6.7_2.6.7-3.diff.gz I'll get on this right away. . . . I don't really see anything that stands out in my brain, so I think PaX will apply pretty cleanly to this. icebox linux-2.6.7-deb # patch -p1 < ../kernel-source-2.6.7_2.6.7-3.diff patching file debian/changelog patching file debian/control patching file debian/apply patching file debian/patches/drivers-sb-pnp_unregister.dpatch patching file debian/patches/fs-cramfs-constify.dpatch patching file debian/patches/fs-jfs-compile.dpatch patching file debian/patches/netlink-macro-fixups.dpatch patching file debian/patches/acpi-typo.dpatch patching file debian/patches/envp.dpatch patching file debian/patches/include-linux-mca.h-fixups.dpatch patching file debian/patches/x86-i486_emu.dpatch patching file debian/patches/doc-post_halloween.dpatch patching file debian/patches/fs-isofs-acorn.dpatch patching file debian/patches/drivers-scsi-advansys-dma_api.dpatch patching file debian/patches/modular-ide-pnp.dpatch patching file debian/patches/include-missing-includes.dpatch patching file debian/patches/include-thread_info-ifdefs.dpatch patching file debian/patches/modular-ide.dpatch patching file debian/patches/fs-isofs-dont-check-period.dpatch patching file debian/patches/dont-dereference-netdev.name-before-register_netdev.dpatch patching file debian/patches/drivers-net-tg3-readd.dpatch patching file debian/patches/DPATCH patching file debian/patches/drivers-usb-net-pegasus-startstop_queue.dpatch patching file debian/patches/drivers-net-via_rhine-avoid_bitfield.dpatch patching file debian/patches/remove-references-to-removed-drivers.dpatch patching file debian/patches/drivers-ide-dma-blacklist-toshiba.dpatch patching file debian/patches/alpha-epoch-comment.dpatch patching file debian/patches/ipsec-missing_wakeup.dpatch patching file debian/patches/00list-1 patching file debian/patches/drivers-scsi-generic_proc_info.dpatch patching file debian/patches/drivers-isdn-io_funcs-fixup.dpatch patching file debian/patches/drivers-scsi-sd-NO_SENSE.dpatch patching file debian/patches/extraversion.dpatch patching file debian/patches/alpha-tembits.dpatch patching file debian/patches/drivers-input-psaux-hacks.dpatch patching file debian/patches/drivers-input-hiddev-HIDIOCGUCODE.dpatch patching file debian/patches/drivers-atkbd-quiten.dpatch patching file debian/patches/drivers-scsi_changer.dpatch patching file debian/patches/modular-swsusp.dpatch patching file debian/patches/drivers-dpt_i2o-fixup.dpatch patching file debian/patches/drivers-net-8139too-locking.dpatch patching file debian/patches/drivers-net-irda-dma_api.dpatch patching file debian/patches/modular-vesafb.dpatch patching file debian/patches/chown-gid-check.dpatch patching file debian/patches/drivers-ftape.dpatch patching file debian/patches/fs-asfs.dpatch patching file debian/patches/00list-2 patching file debian/patches/fs-asfs-2.dpatch patching file debian/patches/00list-3 patching file debian/patches/chown-procfs.dpatch patching file debian/patches/3w-9xxx.dpatch patching file debian/patches/marvell-pegasos.dpatch patching file debian/patches/xfs-update.dpatch patching file debian/patches/marvell-mm.dpatch patching file debian/patches/netfilter-signedcharbug.dpatch patching file debian/README.NMU patching file debian/rules patching file debian/make-kernel-patch-pkgs patching file debian/ChangeLog-2.6.7 patching file debian/substvars patching file debian/prune-non-free patching file debian/list-patches patching file debian/unpatch patching file debian/make-substvars patching file debian/copyright patching file debian/substvars.safe patching file debian/official patching file debian/README.Debian So far so good, PaX next, dry run test real quick. icebox linux-2.6.7-
Re: PaX on Debian
On Mon, 26 Jul 2004 13:48, John Richard Moser <[EMAIL PROTECTED]> wrote: > | Before we can even start thinking about PaX on Debian we need to find a > | maintainer for the kernel patch who will package new versions of the > | patch which apply to the Debian kernel source tree. We have had a few > > Are you talking PaX or grsecurity? PaX is significantly less invasive > than grsecurity. There will still be issues, of course. PaX. AFAIK the only PaX kernel-patch package in Debian is the Adamantix kernel source, which has RSBAC and a bunch of other stuff, and the GRSec patch. Neither of them apply to the Debian kernel source tree. > Where would I see debian's 2.6.7 source tree? I'm not a deb user, > remember, so I'll need a tarball or something. http://ftp.debian.org/debian/pool/main/k/ > | We have recently discussed this on at least one of the lists you > | posted to. > > | The end result of the discussion is that GCC is getting another SSP type > | technology known as "mudflap". Mudflap depends on some major new > | features of > | GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the > | Debian GCC people don't want to merge in other patches which have no > | apparent chance of being included upstream. > > Then don't use ProPolice/SSP for now. That seems to be what will happen. I'd rather see SSP included sooner, but I guess it won't happen. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russell Coker wrote: | On Mon, 26 Jul 2004 02:57, John Richard Moser <[EMAIL PROTECTED]> wrote: | |>I'm interested in discussing the viability of PaX on Debian. I'd like |>to discuss the changes to the base system that would be made, the costs |>in terms of overhead and compatibility, the gains in terms of security, |>and the mutability (elimination) of the costs. | | | Before we can even start thinking about PaX on Debian we need to find a | maintainer for the kernel patch who will package new versions of the patch | which apply to the Debian kernel source tree. We have had a few flame-wars | about this in the past which have had no positive result because no-one has | volunteered to do the kernel coding work. | | Are you talking PaX or grsecurity? PaX is significantly less invasive than grsecurity. There will still be issues, of course. Where would I see debian's 2.6.7 source tree? I'm not a deb user, remember, so I'll need a tarball or something. |>A PaX protected base system would be best compiled ET_DYN, which can be |>done by using modified spec files or a specially patched gcc to make |>pies-by-default binaries. Certain things don't compile this way; and |>thus would need this functionality disabled (modified spec, -fno-pic |>-nopie). This will be discussed in greater detail later. | | | Debian does not use spec files, spec files are for RPM based distributions. | It would have to be a modification to debian/rules in all the packages, or a | modification to gcc and/or dpkg-buildpackage. | No, gcc spec files, that tell gcc how to behave. This was used on gentoo to mess with gcc's default behavior for a while. try the command: gcc -dumpspecs Also try looking at: /usr/lib/gcc-lib///specs You'd need to fudge that file I believe to alter gcc's default behavior. ~ This was done by the Hardened Gentoo project, but was dropped in favor of a gcc patch. Either way, it's been done before. | |>A PaX protected base would also benefit from Stack Smash Protection, |>which can be done via the gcc patch ProPolice. This imposes minimal |>overhead, which will be discussed in greater detail later. It overlaps |>and extends many of the protections PaX offers, but catches earlier on; |>and is thus a good system to pair with PaX. | | | We have recently discussed this on at least one of the lists you posted to. | The end result of the discussion is that GCC is getting another SSP type | technology known as "mudflap". Mudflap depends on some major new features of | GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the | Debian GCC people don't want to merge in other patches which have no apparent | chance of being included upstream. | Then don't use ProPolice/SSP for now. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitely stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBH75hDd4aOud5P8RAvATAJ4p+Kfut/en14Dwenv7UDez86O2KgCeIJcG kP7jnKii7eDGHwiO39MpJjI= =P617 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: running services in their own little world
On Mon, 26 Jul 2004 07:06, "Milan P. Stanic" <[EMAIL PROTECTED]> wrote: > On Sun, Jul 25, 2004 at 11:02:54AM +1000, Russell Coker wrote: > > On Sun, 25 Jul 2004 02:43, hanasaki <[EMAIL PROTECTED]> wrote: > > > The idea is to run bind, http and other servers in a jail. I am just > > > getting started and know little about it, for now. I was hoping that > > > there were Debian packages that already provided the jail(s) to run > > > these services in. > > > > SE Linux offers a good solution to your problem. However SE Linux > > support in Debian is lacking because I'm the only DD working on it. At > > the moment SE Linux support in Fedora is significantly better. > > LIDS is more simpler. > SE Linux is overkill for simple servers for now, IMO. LIDS used to be in the LSM kernel patch, but got removed before LSM was merged into 2.6.x because it wasn't being maintained. Is LIDS being maintained again? If so when will the patch be submitted to Linus? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: PaX on Debian
On Mon, 26 Jul 2004 02:57, John Richard Moser <[EMAIL PROTECTED]> wrote: > I'm interested in discussing the viability of PaX on Debian. I'd like > to discuss the changes to the base system that would be made, the costs > in terms of overhead and compatibility, the gains in terms of security, > and the mutability (elimination) of the costs. Before we can even start thinking about PaX on Debian we need to find a maintainer for the kernel patch who will package new versions of the patch which apply to the Debian kernel source tree. We have had a few flame-wars about this in the past which have had no positive result because no-one has volunteered to do the kernel coding work. > A PaX protected base system would be best compiled ET_DYN, which can be > done by using modified spec files or a specially patched gcc to make > pies-by-default binaries. Certain things don't compile this way; and > thus would need this functionality disabled (modified spec, -fno-pic > -nopie). This will be discussed in greater detail later. Debian does not use spec files, spec files are for RPM based distributions. It would have to be a modification to debian/rules in all the packages, or a modification to gcc and/or dpkg-buildpackage. > A PaX protected base would also benefit from Stack Smash Protection, > which can be done via the gcc patch ProPolice. This imposes minimal > overhead, which will be discussed in greater detail later. It overlaps > and extends many of the protections PaX offers, but catches earlier on; > and is thus a good system to pair with PaX. We have recently discussed this on at least one of the lists you posted to. The end result of the discussion is that GCC is getting another SSP type technology known as "mudflap". Mudflap depends on some major new features of GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the Debian GCC people don't want to merge in other patches which have no apparent chance of being included upstream. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
. . . .thunderbird is being weird. It's giving me > where >> should be,
and >> wehre > should be. EH.
Andres Salomon wrote:
| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
|
|
| I'm interested in discussing the viability of PaX on Debian. I'd like
| to discuss the changes to the base system that would be made, the costs
| in terms of overhead and compatibility, the gains in terms of security,
| and the mutability (elimination) of the costs.
|
|
|
|
|> I think debian-kernel would be a better place to discuss this (at least,
|> the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have
|> been very pleased with it. I would love to be able to include it in
|> debian 2.6 kernels, but we need to make sure that:
|
|> a) it's stable (currently, we have a glibc bug that breaks PAX; #245563.
|> I've also heard reports of various grsec problems on 2.6; I don't
know how
|> many of those are PAX issues)
PaX is stable, grsecurity I can't comment on.
I'm only suggesting PaX. PaX is interestingly enough hosted by
grsecurity; PaX' previous hosting cost money.
http://pax.grsecurity.net/
|> b) it doesn't introduce significant overhead (we need *real*, up-to-date
|> benchmarks here); i'm told that there have been optimizations to PAGEEXEC
|> that make it comparable in speed to SEGMEXEC, but I haven't tried it.
Anything that gives you an executable area existing above data will lose
the PAGEEXEC speedup. This speedup is the same kind of thing Exec
Shield does; except that when data exists in the code segment, it falls
back to old PAGEEXEC rather than becoming executable like Exec Shield does.
On 64 bit (amd64 for example) and other Hardware NX supporting
processors, there will be *no* overhead imposed by PAGEEXEC. :)
|> c) it doesn't introduce limitations (SEGMEXEC isn't an option, for
|> example, since it splits the process address space in half, and can't be
|> turned off to reclaim address space) that aren't easily disabled.
I can give a patch that will allow pax_defaultnx={segm|page}exec on the
kernel command line.
Also, paxctl/chpax can mark binaries to disable segmexec/pageexec.
|
|
|
| A PaX protected base system would be best compiled
|
|> ET_DYN, which can be
|
| done by using modified spec files or a specially patched gcc to make
| pies-by-default binaries. Certain things don't compile this way; and
| thus would need this functionality disabled (modified spec, -fno-pic -
| -nopie). This will be discussed in greater detail later.
|
| A PaX protected base would also benefit from Stack Smash Protection,
| which can be done via the gcc patch ProPolice. This imposes minimal
| overhead, which will be discussed in greater detail later. It overlaps
| and extends many of the protections PaX offers, but catches earlier on;
| and is thus a good system to pair with PaX.
|
|
|
|> I haven't tried SSP yet, but I've heard good things about it. I'll have
|> to do research on it when I have more free time.
|
:) http://en.wikipedia.org/wiki/Stack_smash_protection (same as the
ProPolice article, which is a redirect) shows how this works.
|
|
| PaX is a kernel level
|
|> patch, so certain kernel settings would be needed.
|
| ~ Some of the settings available in PaX are high-overhead or break
| things in a way which cannot be worked around, and should thus be off.
| These will be discussed later.
|
|
|
|> Yes. We cannot have major regressions in the kernel, with the
|> introduction of something like this.
|
|
There will be breakage in places; but I can point out the settings that
cause permenant breakage. All of the other breakage will be solvable
simply by using paxctl/chpax to mark the affected binaries. These can
be distributed marked up properly in their .deb packages.
|
| The costs in terms of overhead of PaX (on legacy x86 systems where it
| must emulate an NX bit) and ProPolice are both very minimal. With
| PAGEEXEC on hardware NX supported systems such as AMD64, there is no
| measurable overhead from PaX. ProPolice brings no significant overhead;
| measurements taken for StackGuard (a similar system which puts the
| canaries in a different place, but is otherwise identical) are available
| for this. This will be discussed in detail later.
|
|
|
|> Do you have any real benchmarks showing exactly how much overheard is
|> added on common hardware (i386, powerpc, and amd64)? I'm merely
|> interested in 2.6.
|
No real benchmarks. I did a SEGMEXEC test on 2.6 that showed a scalar
0.6% overhead from full PaX (aslr and SEGMEXEC emulation), by compiling
the same kernel twice:
1. Compile a kernel, install it
2. Patch the source tree with PaX, and repete 1
3. `make clean` in the original source tree
4. `make menuconfig` in the original source tree to regenerate
dependency data
5. Reboot into the non-PaX kernel
6. `time -p make all` in the source tree (makes bzImage and modules)
7. Repete steps 3 through 6 with the PaX kernel
8. Divide the
Re: [SECURITY] [DSA 531-1] New php4 packages fix multiple vulnerabilities
On Mon, Jul 26, 2004 at 01:32:24AM +0200, Hilko Bengen wrote:
> I imagine that some work on these checks could be saved if security
> updates generally used a scheme like ${LAST_USED_VERSION}woody${N}.
Have you considered that this might be part of the reason why the security
team uses the version numbers they do, and that you are proposing their own
current working practices as a solution?
Additionally, the package maintainer knows which version numbers have been
used and where, and so if he chooses a different scheme, he very likely
knows what he is doing.
This thread started because you noticed something you hadn't seen before,
but it is not particularly unusual, works well, and there is no reason to
change it. I've explained the reason why it was not what you expected, and
so there is no more cause for concern, so I do not think there is a need to
discuss this further.
> Is this part of the the procedure for security updates documented
> anywhere? I didn't find it in the Debian Policy.
I can't count the number of times I've posted this link here; I should have
a mutt hotkey for it.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 531-1] New php4 packages fix multiple vulnerabilities
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> On Sun, Jul 25, 2004 at 11:54:56PM +0200, Hilko Bengen wrote:
>
>> I haven't checked whether this has been the case and, given that
>> PHP has evolved quite a bit since Woody was released, it might not
>> have mattered much in this particular case. But if Debian manages
>> to release more often in the future and less-frequently updated
>> packages are treated like this, we might run into confusion.
>
> Selecting an appropriate version number is part of the security
> update process, and includes checking that it is unique.
I imagine that some work on these checks could be saved if security
updates generally used a scheme like ${LAST_USED_VERSION}woody${N}.
(BTW, what is the quickest/best way to determine if a version number
has been used before?) This would not help in the rare case where a
fix can't be backported, of course.
Is this part of the the procedure for security updates documented
anywhere? I didn't find it in the Debian Policy.
Thanks for your clarification, anyhow. :-)
-Hilko
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'm interested in discussing the viability of PaX on Debian. I'd like > to discuss the changes to the base system that would be made, the costs > in terms of overhead and compatibility, the gains in terms of security, > and the mutability (elimination) of the costs. > I think debian-kernel would be a better place to discuss this (at least, the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have been very pleased with it. I would love to be able to include it in debian 2.6 kernels, but we need to make sure that: a) it's stable (currently, we have a glibc bug that breaks PAX; #245563. I've also heard reports of various grsec problems on 2.6; I don't know how many of those are PAX issues) b) it doesn't introduce significant overhead (we need *real*, up-to-date benchmarks here); i'm told that there have been optimizations to PAGEEXEC that make it comparable in speed to SEGMEXEC, but I haven't tried it. c) it doesn't introduce limitations (SEGMEXEC isn't an option, for example, since it splits the process address space in half, and can't be turned off to reclaim address space) that aren't easily disabled. > A PaX protected base system would be best compiled ET_DYN, which can be > done by using modified spec files or a specially patched gcc to make > pies-by-default binaries. Certain things don't compile this way; and > thus would need this functionality disabled (modified spec, -fno-pic - > -nopie). This will be discussed in greater detail later. > > A PaX protected base would also benefit from Stack Smash Protection, > which can be done via the gcc patch ProPolice. This imposes minimal > overhead, which will be discussed in greater detail later. It overlaps > and extends many of the protections PaX offers, but catches earlier on; > and is thus a good system to pair with PaX. > I haven't tried SSP yet, but I've heard good things about it. I'll have to do research on it when I have more free time. > PaX is a kernel level patch, so certain kernel settings would be needed. > ~ Some of the settings available in PaX are high-overhead or break > things in a way which cannot be worked around, and should thus be off. > These will be discussed later. > Yes. We cannot have major regressions in the kernel, with the introduction of something like this. > The costs in terms of overhead of PaX (on legacy x86 systems where it > must emulate an NX bit) and ProPolice are both very minimal. With > PAGEEXEC on hardware NX supported systems such as AMD64, there is no > measurable overhead from PaX. ProPolice brings no significant overhead; > measurements taken for StackGuard (a similar system which puts the > canaries in a different place, but is otherwise identical) are available > for this. This will be discussed in detail later. > Do you have any real benchmarks showing exactly how much overheard is added on common hardware (i386, powerpc, and amd64)? I'm merely interested in 2.6. > The costs in terms of compatibility with PaX and ProPolice are also > minimal, and mutable. PaX breaks a handful of packages; but all of > these can easily be marked via the chpax and/or paxctl tools to disable > the protections that break them. ProPolice is set off by some programs > (firefox for one), which simply must be compiled without ProPolice > (-fno-stack-protector -fno-stack-protector-all). In terms of the packages that are known to break, how many of them are fixable? Do you have a list of the packages that break? > > Neither of these systems delivers a cost in terms of complexity of use > to the user; these are both 100% transparent to the user. Added I disagree with that; we don't know how many 3rd-party binary apps PAX will kill. However, I'm not overly concerned with that right now, as it's the sort of thing that we won't be able to measure without actually having people using PAX. > complexity in the form of configuring the PaX kernel; setting up the > binary markings for packages that break; and disabling the gcc > modifications for things that break are taken up by the distribution. > > Both of these systems bring a significant security gain. ProPolice Agreed. I've seen PAX/grsec stop numerous attacks on our boxes. > prevents buffer overflow attacks, turning them into program crashes (DoS > attacks). Some buffer overflows, especially for buffers in structures > adjacent to function pointers or other pointers, can escape the > ProPolice logic, however; thus PaX is also needed. This will be > explained in greater detail later. > > A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX > and makes a good read for this. Likewise, one for Stack Smash > Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to > look over. > > Please reply and cite specific concepts you would like to discuss > further. I would rather not wri
RE: [SECURITY] [DSA 531-1] New php4 packages fix multiple vulnerabilities
Hilko Bengen wrote: > > This is the first time I noticed the Debian version being bumped... I > see a potential (general) problem with this: 4.1.2-7 might have > existed in both Woody and Sarge and reflected different states of the > package in each distribution. Except that's not the case. We jumped from 4.1.2-4 to 4.2.1-1. That's why I have made several (-5, -6, -7) 4.1.2 updates to stable with major debian version jumps. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Kemp wrote: [...] |>Firefox sets off SSP itself on load. | | | When you say 'sets of' do you mean disable? I find that unlikely, | as it's not the kind of thing that can be disabled when all the | canary checking code is incorporated into the binary... | | http://bugs.gentoo.org/show_bug.cgi?id=45671 Ok so not on load, more like on competant use. |>"Stack Smash Protection" is the new name of ProPolice? o_o Thought |>that was the name of the concept. | | | SSP is the name for one implementation of stack smashing protection | which was previously known as ProPolice. | It's available from IBM at the following URL: | | http://www.trl.ibm.com/projects/security/ssp/ | | [...] | | Steve | -- - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitely stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBDlRhDd4aOud5P8RAtNhAJ9aXKEKyl0w8oNk64NKXQTVJ54VawCfdCQV YLGFa1P8V2hn0F8wClDmkS0= =KIyO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Kemp wrote: | On Sun, Jul 25, 2004 at 02:26:15PM -0400, John Richard Moser wrote: | | |>| I have been flirting with SSP for months now, but the most recent |>| patches included with GCC do not apply cleanly. Watch for a bug |>| against GCC shortly with updated SSP patches. |>| |> |>Yeah I think on 3.3.4 on Gentoo has SSP | | | It does. | | |>The binutils adds the header field needed for the PaX flags for paxctl. |>~ This is important, because chpax uses an "unused" area in the header, |>which is depricated. Also, tools like strip will zero the chpax flags, |>making them extremely volitile. | | | Shouldn't strip be updated to ignore this 'unused' field, or | would it be more sensible to set aside a real area for the flag? Read again "The binutils adds the header field needed for the PaX flags for paxctl" | ELF | is simple to update with new sections and maybe adding support for | the runtime loader/linker would be more future proof.. | | |>| SSP is remarkably simple to apply and works with all packages I've |>| been able to test on x86. |>| |> |>Firefox sets off SSP itself on load. | | | When you say 'sets of' do you mean disable? I find that unlikely, | as it's not the kind of thing that can be disabled when all the | canary checking code is incorporated into the binary... | I mean firefox DIES due to a segfault. SSP segfaults when it detects an overflow. If you know something we don't, I think the Hardened Gentoo team would like to know | |>"Stack Smash Protection" is the new name of ProPolice? o_o Thought |>that was the name of the concept. | | | SSP is the name for one implementation of stack smashing protection | which was previously known as ProPolice. | It's available from IBM at the following URL: | | http://www.trl.ibm.com/projects/security/ssp/ | :) | |>| I've not noticed this - Mozilla certainly seems fine with SSP |>| compilers. I've been using it on my own unstable boxes for some |>| time. What, specifically, breaks? |>| |> |>Not sure. I'm going by what I've been told by the Gentoo devs; I'm a |>Hardened Gentoo user. | | | But interested in Debian? | I'm interested in getting transparent (i.e. no extra passwords, no extra user configuration, no extra user hassle) security enhancements like PaX and SSP into the base distributions of regular Linux distros, as I believe they are appropriate for machines not operating in a secure environment. I've went at Mandrake and SuSE too, but they ignore me. Machines in a secure environment will be interested in Adamantix or full Hardened Gentoo, or whatever Red Hat Enterprise Server or whatever it's called that has 1 security features comes out. This is because they will host sensitive data, and probably be faced with more direct attacks. Machines *NOT* in a secure environment, however, will benefit from the simpler, transparent subset of features that a secure system provides. They won't be up for containing a security breach; but they'll be safely protected from any weird Sasser or MSBlast type worms and other annoyances. As it stands now, every little security hole in MS RPC or other system services on Windows needs a patch to fix it. Before these patches come out, millions of machines get infected with worms that use the security holes to get into the machines. Linux is not immune; if we had 98% of the market share, every little hole in everything would result in millions of desktop users getting flooded with these things too. There's no harm in BLOCKING THIS CRAP from ever happening. It's not going to bug the users with 5000 extra passwords, it's not going to require a USB stick with an RSA key on it to boot, and it's not going to eat up 50% of your CPU's processing power. Furthermore, using these systems NOW will bring them further into the field, exposing more attacks that get around them. There is no security in obscurity; we're simply faced with what we can and can't stop, and from this we fix things so we CAN stop them, or we tell everyone when there's a SEVERE security issue that we can't deflect. | |>SELinux and SSP do two different things. SSP prevents the program from |>being exploited; SELinux contains the exploit. | | | That's a simplistic explaination .. but it's not too far from | the truth ;) | Hey. Simple is good. | |>PaX also aims to prevent the program from being exploited. | | | The randomization is an interesting technique and it seems | sufficiently simple concept that it would be interesting to | see how well it works. | Did you read the wikipedia article and the docs? :P The restriction of mprotect() is also an interesting technique, as it lets you force programs to listen to you. In fact, I've had issues with things like Flash and Java plug-ins demanding an executable stack, and I've simply used execstack -c to turn that off. PaX can emulate trampolines, which is why the executable stack is needed in the first pl
Re: PaX on Debian
On Sun, Jul 25, 2004 at 02:26:15PM -0400, John Richard Moser wrote: > | I have been flirting with SSP for months now, but the most recent > | patches included with GCC do not apply cleanly. Watch for a bug > | against GCC shortly with updated SSP patches. > | > > Yeah I think on 3.3.4 on Gentoo has SSP It does. > The binutils adds the header field needed for the PaX flags for paxctl. > ~ This is important, because chpax uses an "unused" area in the header, > which is depricated. Also, tools like strip will zero the chpax flags, > making them extremely volitile. Shouldn't strip be updated to ignore this 'unused' field, or would it be more sensible to set aside a real area for the flag? ELF is simple to update with new sections and maybe adding support for the runtime loader/linker would be more future proof.. > | SSP is remarkably simple to apply and works with all packages I've > | been able to test on x86. > | > > Firefox sets off SSP itself on load. When you say 'sets of' do you mean disable? I find that unlikely, as it's not the kind of thing that can be disabled when all the canary checking code is incorporated into the binary... > "Stack Smash Protection" is the new name of ProPolice? o_o Thought > that was the name of the concept. SSP is the name for one implementation of stack smashing protection which was previously known as ProPolice. It's available from IBM at the following URL: http://www.trl.ibm.com/projects/security/ssp/ > | I've not noticed this - Mozilla certainly seems fine with SSP > | compilers. I've been using it on my own unstable boxes for some > | time. What, specifically, breaks? > | > > Not sure. I'm going by what I've been told by the Gentoo devs; I'm a > Hardened Gentoo user. But interested in Debian? > SELinux and SSP do two different things. SSP prevents the program from > being exploited; SELinux contains the exploit. That's a simplistic explaination .. but it's not too far from the truth ;) > PaX also aims to prevent the program from being exploited. The randomization is an interesting technique and it seems sufficiently simple concept that it would be interesting to see how well it works. Steve -- pgpAUdpbcMtqh.pgp Description: PGP signature
Re: [SECURITY] [DSA 531-1] New php4 packages fix multiple vulnerabilities
On Sun, Jul 25, 2004 at 11:54:56PM +0200, Hilko Bengen wrote: > Matt Zimmerman <[EMAIL PROTECTED]> writes: > > > On Thu, Jul 22, 2004 at 04:25:30PM +0200, Hilko Bengen wrote: > > > >> Why has a new Debian version been introduced? Previous security > >> fixes followed a numbering scheme 4.1.2-6woody$i, the last version > >> being 4.1.2-6woody3. > > > > That scheme is used for non-maintainer uploads. The maintainer > > prepared this package, however, and chose to use 4.1.2-7. > > This is the first time I noticed the Debian version being bumped... I > see a potential (general) problem with this: 4.1.2-7 might have > existed in both Woody and Sarge and reflected different states of the > package in each distribution. > > I haven't checked whether this has been the case and, given that PHP > has evolved quite a bit since Woody was released, it might not have > mattered much in this particular case. But if Debian manages to > release more often in the future and less-frequently updated packages > are treated like this, we might run into confusion. Selecting an appropriate version number is part of the security update process, and includes checking that it is unique. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 531-1] New php4 packages fix multiple vulnerabilities
Matt Zimmerman <[EMAIL PROTECTED]> writes: > On Thu, Jul 22, 2004 at 04:25:30PM +0200, Hilko Bengen wrote: > >> Why has a new Debian version been introduced? Previous security >> fixes followed a numbering scheme 4.1.2-6woody$i, the last version >> being 4.1.2-6woody3. > > That scheme is used for non-maintainer uploads. The maintainer > prepared this package, however, and chose to use 4.1.2-7. This is the first time I noticed the Debian version being bumped... I see a potential (general) problem with this: 4.1.2-7 might have existed in both Woody and Sarge and reflected different states of the package in each distribution. I haven't checked whether this has been the case and, given that PHP has evolved quite a bit since Woody was released, it might not have mattered much in this particular case. But if Debian manages to release more often in the future and less-frequently updated packages are treated like this, we might run into confusion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: running services in their own little world
On Sun, Jul 25, 2004 at 11:02:54AM +1000, Russell Coker wrote: > On Sun, 25 Jul 2004 02:43, hanasaki <[EMAIL PROTECTED]> wrote: > > The idea is to run bind, http and other servers in a jail. I am just > > getting started and know little about it, for now. I was hoping that > > there were Debian packages that already provided the jail(s) to run > > these services in. > > SE Linux offers a good solution to your problem. However SE Linux support in > Debian is lacking because I'm the only DD working on it. At the moment SE > Linux support in Fedora is significantly better. LIDS is more simpler. SE Linux is overkill for simple servers for now, IMO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX security and kernel-patch-grsecurity2 and trustees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hanasaki wrote: | what is the relationship between PaX, grsecurity and trustees? | PaX is a separate project from grsecurity. The grsecurity developer finds interest in PaX, and so supplies it with grsecurity. Dunno about trustees. | Will the kernel-patch-grsecurity2 work against 2.6.x from kernel.org | built with kernel-package? | | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitely stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBB1ihDd4aOud5P8RArMGAJ9kRn+lhFgfZZuEBjmt/HZLz8OmjACeN7nt oIew1RsrdJS5oR/o03fNFv8= =tgfv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
PaX security and kernel-patch-grsecurity2 and trustees
what is the relationship between PaX, grsecurity and trustees? Will the kernel-patch-grsecurity2 work against 2.6.x from kernel.org built with kernel-package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Kemp wrote: | On Sun, Jul 25, 2004 at 12:57:29PM -0400, John Richard Moser wrote: | | |>A PaX protected base would also benefit from Stack Smash Protection, |>which can be done via the gcc patch ProPolice. | | | I have been flirting with SSP for months now, but the most recent | patches included with GCC do not apply cleanly. Watch for a bug | against GCC shortly with updated SSP patches. | Yeah I think on 3.3.4 on Gentoo has SSP | |> This imposes minimal overhead, which will be discussed in |>greater detail later. It overlaps and extends many of the protections |>PaX offers, but catches earlier on; and is thus a good system to pair |>with PaX. | | | I've not looked at the combination, but there is already a patched | binutils for PaX available unofficially for unstable, and I have | gcc patched with SSP (lags behind unstable releases - currently | a little out of date due to the breakages recently). | The binutils adds the header field needed for the PaX flags for paxctl. ~ This is important, because chpax uses an "unused" area in the header, which is depricated. Also, tools like strip will zero the chpax flags, making them extremely volitile. | | http://people.debian.org/~skx/ssp.html | | |>PaX is a kernel level patch, so certain kernel settings would be needed. |>~ Some of the settings available in PaX are high-overhead or break |>things in a way which cannot be worked around, and should thus be off. |>These will be discussed later. | | | SSP is remarkably simple to apply and works with all packages I've | been able to test on x86. | Firefox sets off SSP itself on load. | |>The costs in terms of compatibility with PaX and ProPolice are also | | | Probably less confusing to all if you refer to ProPolice by | its new name, SSP, exclusively. | "Stack Smash Protection" is the new name of ProPolice? o_o Thought that was the name of the concept. | |>the protections that break them. ProPolice is set off by some programs |>(firefox for one), which simply must be compiled without ProPolice |>(-fno-stack-protector -fno-stack-protector-all). | | | I've not noticed this - Mozilla certainly seems fine with SSP | compilers. I've been using it on my own unstable boxes for some | time. What, specifically, breaks? | Not sure. I'm going by what I've been told by the Gentoo devs; I'm a Hardened Gentoo user. | |>Both of these systems bring a significant security gain. ProPolice |>prevents buffer overflow attacks, turning them into program crashes (DoS |>attacks). Some buffer overflows, especially for buffers in structures |>adjacent to function pointers or other pointers, can escape the |>ProPolice logic, however; thus PaX is also needed. This will be |>explained in greater detail later. | | | I've keep a running log of all the security holes I've discovered, | and more recently those by other members and a note as to whether | SSP protects against them. | | This is available here: | | http://shellcode.org/Advisories/ | cool. | As you can see many, but not all, attacks are protected against | with SSP. SELinux would almost certainly do better ... (Because | the things that aren't protected against are failure to drop | privileges when using popen/system - SELinux could protect against | this, SSP cannot). | SELinux and SSP do two different things. SSP prevents the program from being exploited; SELinux contains the exploit. PaX also aims to prevent the program from being exploited. | |>Please reply and cite specific concepts you would like to discuss |>further. I would rather not write up a 10 page paper by explaining all |>of these at once; but if demanded, I'll do just that. Be ready to |>swallow a large pill though. | | | Looking forward to it already! | | Steve | -- | # The Debian Security Audit Project. | http://www.debian.org/security/audit | - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitely stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBA/tFhDd4aOud5P8RAibQAJ9ybg/PKG6OslYh4EbFKBRVP/N+zQCeOu8E TYorBgIvKO35LMneplcdjbs= =BbdL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
On Sun, Jul 25, 2004 at 12:57:29PM -0400, John Richard Moser wrote: > A PaX protected base would also benefit from Stack Smash Protection, > which can be done via the gcc patch ProPolice. I have been flirting with SSP for months now, but the most recent patches included with GCC do not apply cleanly. Watch for a bug against GCC shortly with updated SSP patches. > This imposes minimal overhead, which will be discussed in > greater detail later. It overlaps and extends many of the protections > PaX offers, but catches earlier on; and is thus a good system to pair > with PaX. I've not looked at the combination, but there is already a patched binutils for PaX available unofficially for unstable, and I have gcc patched with SSP (lags behind unstable releases - currently a little out of date due to the breakages recently). http://people.debian.org/~skx/ssp.html > PaX is a kernel level patch, so certain kernel settings would be needed. > ~ Some of the settings available in PaX are high-overhead or break > things in a way which cannot be worked around, and should thus be off. > These will be discussed later. SSP is remarkably simple to apply and works with all packages I've been able to test on x86. > The costs in terms of compatibility with PaX and ProPolice are also Probably less confusing to all if you refer to ProPolice by its new name, SSP, exclusively. > the protections that break them. ProPolice is set off by some programs > (firefox for one), which simply must be compiled without ProPolice > (-fno-stack-protector -fno-stack-protector-all). I've not noticed this - Mozilla certainly seems fine with SSP compilers. I've been using it on my own unstable boxes for some time. What, specifically, breaks? > Both of these systems bring a significant security gain. ProPolice > prevents buffer overflow attacks, turning them into program crashes (DoS > attacks). Some buffer overflows, especially for buffers in structures > adjacent to function pointers or other pointers, can escape the > ProPolice logic, however; thus PaX is also needed. This will be > explained in greater detail later. I've keep a running log of all the security holes I've discovered, and more recently those by other members and a note as to whether SSP protects against them. This is available here: http://shellcode.org/Advisories/ As you can see many, but not all, attacks are protected against with SSP. SELinux would almost certainly do better ... (Because the things that aren't protected against are failure to drop privileges when using popen/system - SELinux could protect against this, SSP cannot). > Please reply and cite specific concepts you would like to discuss > further. I would rather not write up a 10 page paper by explaining all > of these at once; but if demanded, I'll do just that. Be ready to > swallow a large pill though. Looking forward to it already! Steve -- # The Debian Security Audit Project. http://www.debian.org/security/audit pgpWiPEETMzly.pgp Description: PGP signature
PaX on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm interested in discussing the viability of PaX on Debian. I'd like to discuss the changes to the base system that would be made, the costs in terms of overhead and compatibility, the gains in terms of security, and the mutability (elimination) of the costs. A PaX protected base system would be best compiled ET_DYN, which can be done by using modified spec files or a specially patched gcc to make pies-by-default binaries. Certain things don't compile this way; and thus would need this functionality disabled (modified spec, -fno-pic - -nopie). This will be discussed in greater detail later. A PaX protected base would also benefit from Stack Smash Protection, which can be done via the gcc patch ProPolice. This imposes minimal overhead, which will be discussed in greater detail later. It overlaps and extends many of the protections PaX offers, but catches earlier on; and is thus a good system to pair with PaX. PaX is a kernel level patch, so certain kernel settings would be needed. ~ Some of the settings available in PaX are high-overhead or break things in a way which cannot be worked around, and should thus be off. These will be discussed later. The costs in terms of overhead of PaX (on legacy x86 systems where it must emulate an NX bit) and ProPolice are both very minimal. With PAGEEXEC on hardware NX supported systems such as AMD64, there is no measurable overhead from PaX. ProPolice brings no significant overhead; measurements taken for StackGuard (a similar system which puts the canaries in a different place, but is otherwise identical) are available for this. This will be discussed in detail later. The costs in terms of compatibility with PaX and ProPolice are also minimal, and mutable. PaX breaks a handful of packages; but all of these can easily be marked via the chpax and/or paxctl tools to disable the protections that break them. ProPolice is set off by some programs (firefox for one), which simply must be compiled without ProPolice (-fno-stack-protector -fno-stack-protector-all). Neither of these systems delivers a cost in terms of complexity of use to the user; these are both 100% transparent to the user. Added complexity in the form of configuring the PaX kernel; setting up the binary markings for packages that break; and disabling the gcc modifications for things that break are taken up by the distribution. Both of these systems bring a significant security gain. ProPolice prevents buffer overflow attacks, turning them into program crashes (DoS attacks). Some buffer overflows, especially for buffers in structures adjacent to function pointers or other pointers, can escape the ProPolice logic, however; thus PaX is also needed. This will be explained in greater detail later. A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX and makes a good read for this. Likewise, one for Stack Smash Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to look over. Please reply and cite specific concepts you would like to discuss further. I would rather not write up a 10 page paper by explaining all of these at once; but if demanded, I'll do just that. Be ready to swallow a large pill though. - --John - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitely stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBA+Z4hDd4aOud5P8RAqTjAJ45bMPCCW04EeDjX+NZP9m3UmC3rgCfSzt2 78Qydi7ZCMdO6vdRXuH/ZMw= =2QiO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
