From: Alexander Economou <aecon@gnet.gr>
To: Benjamin Walkenhorst <krylon@gmx.net>
Cc: linux-admin@vger.kernel.org
Subject: Re: Securing my machine
Date: Mon, 1 Dec 2003 12:54:05 +0200 [thread overview]
Message-ID: <1070276045.3fcb1dcdc83bb@mail.gnet.gr> (raw)
In-Reply-To: <200311251843.38934.krylon@gmx.net>
Quoting Benjamin Walkenhorst <krylon@gmx.net>:
> Hello everybody,
>
> I use Slackware 9.1 on my desktop-machine. I do so quite happily, it
> took only a week for Slackware to become my new primary OS. =)
>
> I connect to the internet through a small server/gateway running
> NetBSD-1.6.1. The gateway connects to my ISP via ISDN-dial-up
> connection.
> The NetBSD-machine runs ipf (NetBSD's packet filter, roughly equivalent
> to iptables) and IPNAT.
>
> I run gtk-gnutella on my desktop-machine from time to time. Since I want
> others to be able to connect to my machine (also, for getting
> push-connections), I decided to forward the corresponding port to my
> Linux-machine.
> This has even shown to work fine, thanks. =)
>
> But I am getting a little concerned about letting others connect to my
> machine. Since my desktop-machine is behind a firewall, also since I am
> the only user on my home-network, I did not exactly take care to secure
> my Linux-machine.
> Now I am getting worried someone might break into my machine via
> GNUtella. I don't think gtk-gnutella was written with security in
> mind...
>
> So I want to tighten the security on my Linux machine in a way that
> includes minimal inconvenience. Of course, I am going to start with all
> the usual stuff, like installing tripwire, shutting down unneeded
> services (in fact, I do this by default after installation), taking
> care of file-permissions, cleaning up unneeded suid/sgid-bits, and so
> on.
>
> But then I read, most of all network-attacks are done via
> buffer-overflows, so this is what I am most concerned about. I hear,
> there's basically two ways of handling this problem:
> - Using MAC/RBAC for controlling the ressources an application can
> access - if it's getting compromised, it won't be able to harm the
> system (seLinux).
> - Preventing buffer-overflows in the first place. There's several
> options how to achieve this, the most important are a) applying
> patches to the kernel (PaX, grSecurity) or to the GNU C Compiler
> (ProPolice)
>
> In general, preventing buffer-overflows at all seems preferrable to me,
> since it does not seem to require that much work. Also, this is they
> way the OpenBSD-project has been going, and OpenBSD surely has a
> reputation for first-class security.
> So I got several questions:
> - Has anyone worked with these system-add-ons? Got any experiences to
> share with me?
> - ProPolice sounds nice. But using it would require lots of
> recompiling... What exactly do I have to recompile in order to benefit
> from it? Just the application in question? The libraries, too? The
> kernel? The entire system?
> I am going to evaluate CRUX and Gentoo on my desktop-machine, both of
> which offer the option of recompiling the entire system. If I choose
> to use one of these as my primary system, recompiling won't be a
> problem, any more. As of now, it is, if system libraries or even the
> base system are involved.
> - PaX/grSecurity sound really sweet. But I see on the homepages, there
> are patches available only for linux-kernels 2.4.22. Is 2.6 going to
> be supported in the near future?
> I am using 2.6.0-test8 right now, and I am rather happy with it, so I
> would like to keep using 2.6, once the final version is out.
> On the other hand, I can switch back to 2.4.22 if PaX/grSecurity
> offers serious protection.
> And a lot of grSec's features sound really neat. =) Right now, this
> sounds like the best way to secure my machine, since it invloves only
> minimal setup, just patching and recompiling the kernel, while
> increasing system-security drastically. If I got things right, that
> is...
> - MAC/RBAC does not really sound like I need it. Then again, more
> security never hurts.
> But this also sounds like it is going to be a lot of learning plus a
> lot of effort to get it working. Furthermore, the corresponding
> kernel-patch is developed at the NSA, and I do not exactly trust the
> NSA to contribute to my privacy.
> In order for M/RB-AC to be really useful, I'm afraid, you have to take
> a lot of time to set it up correctly. And, as I said, I do not know
> terribly much about this topic.
> If I get things right, seLinux and grSecurity are not mutually
> exclusive.
>
> So, in general, any information will be appreciated. If there are
> further promising ways of protecting my system against
> buffer-overflows, I would like to know, as well.
> Of course, I like to read a lot, so any hints on where to look for
> information will be appreciated as well (if there's something
> useful/interesting to read, there).
> I am aware of pageexec.virtualave.net (PaX's homepage) and
> grsecurity.net, as well as the NSA's seLinux-page.
> Anything I missed? Anything I should know?
>
> Thank you very much in advance,
>
> Kind regards,
>
> Benjamin Walkenhorst
>
> --
> Benjamin Walkenhorst
> eMail: krylon@gmx.net
> http://www.krylon.de
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I would suggest you should try libsafe and Wolk. You can find libsafe @
freshmeat.net and wolk @ sf.net
prev parent reply other threads:[~2003-12-01 10:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 17:43 Securing my machine Benjamin Walkenhorst
2003-12-01 10:54 ` Alexander Economou [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1070276045.3fcb1dcdc83bb@mail.gnet.gr \
--to=aecon@gnet.gr \
--cc=krylon@gmx.net \
--cc=linux-admin@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).