From bff5a712e09174b055fa1ed57ffbc4f08629cb25 Mon Sep 17 00:00:00 2001 From: Karel Klic Date: Wed, 18 May 2011 18:19:55 +0200 Subject: retrace doc: Security section update --- doc/abrt-retrace-server.texi | 61 ++++++++++++++++++++------------------------ 1 file changed, 27 insertions(+), 34 deletions(-) diff --git a/doc/abrt-retrace-server.texi b/doc/abrt-retrace-server.texi index 29d41414..9eb02ca8 100644 --- a/doc/abrt-retrace-server.texi +++ b/doc/abrt-retrace-server.texi @@ -601,10 +601,12 @@ distribution repositories. @end menu General security from GDB flaws and malicious data is provided by -chroot. The GDB accesses the debuginfos, packages, and the coredump -from within the chroot, unable to access the retrace server's -environment. We should consider setting a disk quota to every chroot -directory, and limit the GDB access to resources using cgroups. +chroot. The GDB accesses the debuginfos, packages, and the coredump from +within the chroot under a non-root user, unable to access the retrace +server's environment. + +@c We should consider setting a disk quota to every chroot directory, +@c and limit the GDB access to resources using cgroups. SELinux policy exists for both the retrace server's HTTP interface, and for the retrace worker. @@ -612,34 +614,25 @@ for the retrace worker. @node Clients @section Clients -The clients, which are using the retrace server and sending coredumps -to it, must fully trust the retrace server administrator. The server -administrator must not try to get sensitive data from client -coredumps. That seems to be a major bottleneck of the retrace server -idea. However, users of an operating system already trust the OS -provider in various important matters. So when the retrace server is -operated by the operating system provider, that might be acceptable by -users. - -We cannot avoid sending clients' coredumps to the retrace server, if we -want to generate quality backtraces containing the values of +It is expected that the clients, which are using the retrace server and +sending coredumps to it, trust the retrace server administrator. The +server administrator must not try to get sensitive data from client +coredumps. This is a major bottleneck of the retrace server. However, +users of an operating system already trust the operating system provider +in various important matters. So when the retrace server is operated by +the OS provider, that might be acceptable for users. + +Sending clients' coredumps to the retrace server cannot be avoided if we +want to generate good backtraces containing the values of variables. Minidumps lower the quality of the resulting backtraces, while not improving user security. -Can the retrace server trust clients? We must know what can a -malicious client achieve by crafting a nonstandard coredump, which -will be processed by server's GDB. We should ask GDB experts about -this. - -Another question is whether we can allow users providing some packages -and debuginfo together with a coredump. That might be useful for -users, who run the operating system only with some minor -modifications, and they still want to use the retrace server. So they -send a coredump together with a few nonstandard packages. The retrace -server uses the nonstandard packages together with the OS packages to -generate the backtrace. Is it safe? We must know what can a malicious -client achieve by crafting a special binary and debuginfo, which will -be processed by server's GDB. +A malicious client can craft a nonstandard coredump, which will be +processed by server's GDB. GDB handles malformed coredumps well. + +Users can never be allowed to provide custom packages/debuginfo together +with a coredump. Packages need to be installed to the environment, and +installing untrusted programs is insecure. As for attacker trying to steal users' backtraces from the retrace server, the passwords protecting the backtraces in the @@ -652,12 +645,12 @@ randomness is @file{/dev/urandom}. @node Packages and debuginfo @section Packages and debuginfo -We can safely download packages and debuginfo from the distribution, -as the packages are signed by the distribution, and the package origin -can be verified. +Packages and debuginfo are safely downloaded from the distribution +repositories, as the packages are signed by the distribution, and the +package origin is verified. -When the debuginfo server is done, the retrace server can safely use -it, as the data will also be signed. +When the debuginfo filesystem server is done, the retrace server can +safely use it, as the data will also be signed. @node Future work @chapter Future work -- cgit