Security Changes For Fedora 9

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

[Christian Iseli]

On Thu, 20 Dec 2007 19:29:29 -0800 (PST), [e-mail]
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

[Tomas Mraz]

On Thu, 2007-12-20 at 19:29 -0800, [e-mail] 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.

[Max]

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
--- [e-mail] 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
> [e-mail]
> 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

[Kevin Fenzi]

On Thu, 20 Dec 2007 19:29:29 -0800 (PST)
[e-mail] 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

[Jason L Tibbitts III]

> > > > > "KF" == Kevin Fenzi  writes:
> > 7: Password Protect Single User Mode (Runlevel 1)

KF> Might be worth doing.

That's what the grub password is for.

- J<

[Greg Metcalfe]

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

[Kevin Fenzi]

On Fri, 4 Jan 2008 17:55:49 -0800 (PST)
[e-mail] 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

[Tomas Hoger]

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.

[David Pullman]

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.

[Ville Skyttä]

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...

[Eric Rannaud]

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@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.

[Ville Skyttä]

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@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.

[Greg Metcalfe]

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@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
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-security-list

[Greg Metcalfe]

On Friday 04 January 2008 05:55:49 pm [e-mail] 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.

[Greg Metcalfe]

On Friday 04 January 2008 05:55:49 pm [e-mail] 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