Security Updates For Fedora 9
Greetings! I had several ideas for Fedora 9 in regards to improving the security of a default installation.
1: Disable root account / Use Sudo
2: /etc/ssh/sshd_config changes -PermitRootLogin no (currently 'yes') -LoginGraceTime 1m (currently 2m) -Banner /etc/issue.net (currently not set) -AllowGroups wheel (currently not set)
We should also see if the OpenSSH developers would be willing to make these changes the default on Portable OpenSSH.
3: Add wheel group if not present If there is no wheel group by default, we should include one in Fedora 9. This means deciding on what Group ID (GID) to use. Anaconda would need to force creation of a user account that is a part of this group.
4: GCC Lockdowns With the new GCC-4.3.0 recently built for Fedora 9, we should forbid ordinary users access to the programs it contains, incl. rpmbuild, mock, etc. Only members of the wheel, koji, and mock groups should have access to software development tools. Did I miss any groups that should be allowed access?
5: Bastille Be sure to incorporate the most important Bastille fixes (www.bastille-linux.org). This project appears to have stalled and requires an older version of Fedora to run, unless you're a Perl ninja =) Maybe we should contact the developer (Jay Beale), and ask him what he needs to revive the project? Perhaps the Fedora community can be of assistance.
6: Make Packages for PortSentry & LogCheck Can we add PortSentry & LogCheck to the list of available Fedora Packages? I know the project appears to have stalled since late 2003.
7: Password Protect Single User Mode (Runlevel 1)
8: USB Key Authentication / Dual Factor Authentication Should we use PGP or another tool to allow people to login/logout with a USB drive? This would have to work for KDE and Gnome at the very least, and while we are at it, we might as well support XFCE. Inserting/Removing the USB drive could automatically login/logout the user, with or without a password as a second form of authentication, depending on how Joe Admin wants his security set up.
9: Can we include TrueCrypt as a new package, provided it meets the requirements, such as having an open source license, no patents or copyrights, etc?
Hope these ideas prove useful to the community.
Regards, Riley F. Marquis III Senior Analyst - TCS Research
On Thu, 20 Dec 2007 19:29:29 -0800 (PST), riley.marquis@tcsresearch.org wrote:
With the new GCC-4.3.0 recently built for Fedora 9, we should forbid ordinary users access to the programs it contains, incl. rpmbuild, mock, etc. Only members of the wheel, koji, and mock groups should have access to software development tools. Did I miss any groups that should be allowed access?
Yikes!
We want to encourage people to develop software, not prevent them... That's the whole idea behind free/open-source!
Christian
On Thu, 2007-12-20 at 19:29 -0800, riley.marquis@tcsresearch.org wrote:
Security Updates For Fedora 9
Greetings! I had several ideas for Fedora 9 in regards to improving the security of a default installation.
1: Disable root account / Use Sudo
Maybe more secure from one point of view maybe less secure from another. So please no.
2: /etc/ssh/sshd_config changes -PermitRootLogin no (currently 'yes')
Not before we have a way how to login on remotely installed vnc machine.
-LoginGraceTime 1m (currently 2m)
If upstream changes it then yes.
-Banner /etc/issue.net (currently not set)
sshd doesn't support escape sequences which are currently present in issue.net
-AllowGroups wheel (currently not set)
No.
We should also see if the OpenSSH developers would be willing to make these changes the default on Portable OpenSSH.
They wouldn't except perhaps the LoginGraceTime change.
3: Add wheel group if not present If there is no wheel group by default, we should include one in Fedora 9. This means deciding on what Group ID (GID) to use. Anaconda would need to force creation of a user account that is a part of this group.
There is a wheel group by default with root as a member.
4: GCC Lockdowns With the new GCC-4.3.0 recently built for Fedora 9, we should forbid ordinary users access to the programs it contains, incl. rpmbuild, mock, etc. Only members of the wheel, koji, and mock groups should have access to software development tools. Did I miss any groups that should be allowed access?
Nonsense.
Personally i like being able to log in as root when necessary. This way i don't have to worry about a mis-configured sudoers file. I am still a little green when it comes to the security subject but I think its important for new users to know about the root account and the dangers involved. The advanced users will be able to set things up the way you suggest without any trouble but a new user might be a little bewildered by the whole thing. Distros like Ubuntu setup the first user as admin/root if i am not mistaken, Apple takes the same approach i think though i don't know the particulars of the two setups, it makes me nervous. Feel free to educate me.
-Max --- riley.marquis@tcsresearch.org wrote:
Security Updates For Fedora 9
Greetings! I had several ideas for Fedora 9 in regards to improving the security of a default installation.
1: Disable root account / Use Sudo
2: /etc/ssh/sshd_config changes -PermitRootLogin no (currently 'yes') -LoginGraceTime 1m (currently 2m) -Banner /etc/issue.net (currently not set) -AllowGroups wheel (currently not set)
We should also see if the OpenSSH developers would be willing to make these changes the default on Portable OpenSSH.
3: Add wheel group if not present If there is no wheel group by default, we should include one in Fedora 9. This means deciding on what Group ID (GID) to use. Anaconda would need to force creation of a user account that is a part of this group.
4: GCC Lockdowns With the new GCC-4.3.0 recently built for Fedora 9, we should forbid ordinary users access to the programs it contains, incl. rpmbuild, mock, etc. Only members of the wheel, koji, and mock groups should have access to software development tools. Did I miss any groups that should be allowed access?
5: Bastille Be sure to incorporate the most important Bastille fixes (www.bastille-linux.org). This project appears to have stalled and requires an older version of Fedora to run, unless you're a Perl ninja =) Maybe we should contact the developer (Jay Beale), and ask him what he needs to revive the project? Perhaps the Fedora community can be of assistance.
6: Make Packages for PortSentry & LogCheck Can we add PortSentry & LogCheck to the list of available Fedora Packages? I know the project appears to have stalled since late 2003.
7: Password Protect Single User Mode (Runlevel 1)
8: USB Key Authentication / Dual Factor Authentication Should we use PGP or another tool to allow people to login/logout with a USB drive? This would have to work for KDE and Gnome at the very least, and while we are at it, we might as well support XFCE. Inserting/Removing the USB drive could automatically login/logout the user, with or without a password as a second form of authentication, depending on how Joe Admin wants his security set up.
9: Can we include TrueCrypt as a new package, provided it meets the requirements, such as having an open source license, no patents or copyrights, etc?
Hope these ideas prove useful to the community.
Regards, Riley F. Marquis III Senior Analyst - TCS Research
-- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
On Thu, 20 Dec 2007 19:29:29 -0800 (PST) riley.marquis@tcsresearch.org wrote:
Security Updates For Fedora 9
Greetings!
Greetings.
I had several ideas for Fedora 9 in regards to improving the security of a default installation.
1: Disable root account / Use Sudo
There are tradeoffs here. I personally would like to see it continue to be enabled until we can figure out more of the issues around disabling it.
...snipp...
4: GCC Lockdowns With the new GCC-4.3.0 recently built for Fedora 9, we should forbid ordinary users access to the programs it contains, incl. rpmbuild, mock, etc. Only members of the wheel, koji, and mock groups should have access to software development tools. Did I miss any groups that should be allowed access?
I would also say this is a bad idea. We want people to use the tools on the machine, don't we?
5: Bastille Be sure to incorporate the most important Bastille fixes (www.bastille-linux.org). This project appears to have stalled and requires an older version of Fedora to run, unless you're a Perl ninja =) Maybe we should contact the developer (Jay Beale), and ask him what he needs to revive the project? Perhaps the Fedora community can be of assistance.
We should take a look I agree, but many of the things bastille did/does are not useful these days. Disabling rsh/rlogin? Disabling compilers (your point 4 I guess)? Setting more agressive security defaults on some applications? Many of the things it does we should be doing in the packages we ship, not trying to modify after install.
Would anyone be interested in culling through and coming up with a list of items we should address that bastille does?
6: Make Packages for PortSentry & LogCheck Can we add PortSentry & LogCheck to the list of available Fedora Packages? I know the project appears to have stalled since late 2003.
Personally, I don't find portsentry usefull anymore. The number of port scans that go on anymore means I don't want to hear about blocking specific IP's. I just want everything except specific services blocked by default.
There's nothing preventing someone from submitting packages for fedora however...
7: Password Protect Single User Mode (Runlevel 1)
Might be worth doing. I think the reason it hasn't in the past is that there haven't been good international ways of querying for passwords. With encrypted root and instantX this might be worth looking at.
8: USB Key Authentication / Dual Factor Authentication Should we use PGP or another tool to allow people to login/logout with a USB drive? This would have to work for KDE and Gnome at the very least, and while we are at it, we might as well support XFCE. Inserting/Removing the USB drive could automatically login/logout the user, with or without a password as a second form of authentication, depending on how Joe Admin wants his security set up.
You can already do that with smartcards. Just allowing someone to login with a hardware token seems a bad idea. All someone would need is the usb drive.
9: Can we include TrueCrypt as a new package, provided it meets the requirements, such as having an open source license, no patents or copyrights, etc?
Not possible for fedora. I don't know if the license is acceptable, but it has a kernel module. Fedora doesnt allow kernel modules. Perhaps it could be added to the livna repo?
Hope these ideas prove useful to the community.
You bet... thanks for the input...
Regards, Riley F. Marquis III Senior Analyst - TCS Research
kevin
On Friday 21 December 2007 09:13:21 am Kevin Fenzi wrote: <snip to address only Bastille>
5: Bastille Be sure to incorporate the most important Bastille fixes (www.bastille-linux.org). This project appears to have stalled and requires an older version of Fedora to run, unless you're a Perl ninja =) Maybe we should contact the developer (Jay Beale), and ask him what he needs to revive the project? Perhaps the Fedora community can be of assistance.
Since 2000 or so I, or people I know, have found the Bastille project stalled for a platform that it needed to be evaluated against, on at least three occasions. Pulling it up on rpmfind.net, the last changelog entry reads:
* Sun Apr 16 2006 Jay Beale <email redacted> 3.0.9-1.0 - Added support for Fedora Core 5 - Added support for SUSE 10.0 - Added support for Mandrake 10.0, 10.1, 2006... - Added support for OS X Tiger (10.4) - preliminary
We should take a look I agree, but many of the things bastille did/does are not useful these days. Disabling rsh/rlogin? Disabling compilers (your point 4 I guess)? Setting more agressive security defaults on some applications? Many of the things it does we should be doing in the packages we ship, not trying to modify after install.
Usefulness depends upon what you're doing. For instance, Bastille was supported on HP-UX, though I no longer know how well. I've seen one environment where not only were the Berkeley 'r' programs were still used very heavily, but also rusers, in which case the portmapper had to be accessible. Granted, this is the sort of thing that applies mostly to non-GUI, often headless, installs. This is probably not a typical environment for Fedora, but one that definitely does happen, and with some frequency.
Would anyone be interested in culling through and coming up with a list of items we should address that bastille does?
That would require someone who's running a distro that's pretty old. If I still had a SuSE 10.0 or FC5 box, I'd have already run Bastille in evaluation mode, just to see where it was a couple of years ago. If enough people want to see the information, I'd be willing to load FC5 on a box, on a temporary basis, after the holidays. I could also run it from the source tarball on more recent Fedoras, again in eval mode, just for some comparison data.
Be advised that working alone, it could take me a couple of weeks to produce all the data. Time is somewhat limited. I've not looked at the code in some time, so I don't know if I'd have to run it against, say, a minimal, GNOME, and KDE install for each version. Also, not being familiar with the current code, it could be full of security or other bugs. The bz2 tarball is 312 KB. That's a fair amount of Perl, which may not have received a plethora of eyeballs, and I've no idea what (if any) test harnesses may have been used, etc.
If there's a lot of demand for the information, hopefully someone will also come forward to split the testing load with me. If not, I can live with that, and run everything by mid-January. Actually, I'd *have* to complete it by then, and I can't offer even a cursory code review. Someone may want to take a look at the requires and provides list for some hints about that. This is down to time issues that are beyond my control. My window runs from 1/2/07 through 1/14/07, inclusive. Sorry, folks, but it's the best I can do.
I have to admit that I'm not sanguine about receiving an adequate return on investment from Bastille. The periodic halts in the project could mean a fair commitment of resources to avoid future problems. I've also heard stories from people who were able to run it, but found major problems in the ability of typical end users to use it correctly. Overall quality of code is also a huge unknown.
That said, I'm not wedded to my opinion. This is just my two cents. Actual data is always preferable, if the community decides to seriously explore this. Not knowing exactly how to define that, as I don't know the size of this community, I'm making an arbitrary call that if a dozen people ask me to do it, I will. If any one person volunteers to split the load, I'll do it.
I should probably look for list archives, and grep around for unique posters, just to get an idea of community size. But not today. Last-minute Christmas shopping is the higher priority.
Jingle bells, and best wishes,
Greg
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
On Fri, 4 Jan 2008 17:55:49 -0800 (PST) riley.marquis@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
On Sat, 5 Jan 2008 14:57:44 -0700 Kevin Fenzi kevin@tummy.com 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 wrote:
On Sat, 5 Jan 2008 14:57:44 -0700 Kevin Fenzi kevin@tummy.com 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.
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...
On Jan 10, 2008 10:26 PM, Ville Skyttä ville.skytta@iki.fi 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@tooeasy]$ rpm -q --scripts hacker_pkg.rpm postinstall scriptlet (using /bin/sh): rm -rf / exit 0 [hacker@tooeasy]$ scp -p hackers_pkg.rpm foo@host: [hacker@tooeasy]$ ssh -t foo@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.
On Monday 14 January 2008, Eric Rannaud wrote:
On Jan 10, 2008 10:26 PM, Ville Skyttä ville.skytta@iki.fi 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@tooeasy]$ rpm -q --scripts hacker_pkg.rpm postinstall scriptlet (using /bin/sh): rm -rf / exit 0 [hacker@tooeasy]$ scp -p hackers_pkg.rpm foo@host: [hacker@tooeasy]$ ssh -t foo@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.
On Monday 14 January 2008 11:16:10 am Eric Rannaud wrote:
On Jan 10, 2008 10:26 PM, Ville Skyttä ville.skytta@iki.fi 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@tooeasy]$ rpm -q --scripts hacker_pkg.rpm postinstall scriptlet (using /bin/sh): rm -rf / exit 0 [hacker@tooeasy]$ scp -p hackers_pkg.rpm foo@host: [hacker@tooeasy]$ ssh -t foo@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
On Friday 04 January 2008 05:55:49 pm riley.marquis@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.
On Friday 04 January 2008 05:55:49 pm riley.marquis@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
security@lists.fedoraproject.org