4:47 p.m.
http://www.fedoraproject.org/wiki/SecurityBasics
This page is intended as a stopgap to cover the basic stuff until
tutorials/Guides are released, in particular the "what about viruses"
question that pops up semi-regularly.
It deliberately isn't linked to the FAQ or other pages, until it has
been sanity checked.
--
Stuart Ellis
stuart(a)elsn.org
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
GPG key ID: 7098ABEA
GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA
5:58 p.m.
If one of the goals of Fedora Core is being secure right from the
start, why is the user allowed to enter single-user without supplying
the root password (sulogin)?
6:22 p.m.
On Mon, 10 Oct 2005, Felipe Alfaro Solana wrote:
> http://www.fedoraproject.org/wiki/SecurityBasics
If one of the goals of Fedora Core is being secure right from the
start, why is the user allowed to enter single-user without supplying
the root password (sulogin)?
Because requiring a passwd on a box that you can sit in front of and take apart
is STUPID!! All requiring a passwd for single user mode does is make me have to
go find a rescue disk. What is the point? If you have physical access to the
machine you can get into it. You do not need passwds. Some take a little longer
than others. Why make the inevitable harder?
Think about windoze, Windoze requires a passwd for safe/recovery mode. All that
does for me is make me find my CD case, insert the CD into the drive and boot
from the CD. Machine does not have a CD you say OK now I have to go find a CD
drive to plug into the machine and my CD case. There is a passwd on the BIOS
you say, OK now I have to go find the little jumper on the MB to reset the BIOS
to the factory defaults.
The above applies to windoze and Linux. It does not matter. Where there is a
will there is a way.
Regards,
Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com
6:55 p.m.
On Sun, 2005-10-09 at 19:22 -0400, Tom Diehl wrote:
On Mon, 10 Oct 2005, Felipe Alfaro Solana wrote:
> > http://www.fedoraproject.org/wiki/SecurityBasics
>
> If one of the goals of Fedora Core is being secure right from the
> start, why is the user allowed to enter single-user without supplying
> the root password (sulogin)?
Because requiring a passwd on a box that you can sit in front of and take apart
is STUPID!! All requiring a passwd for single user mode does is make me have to
go find a rescue disk. What is the point? If you have physical access to the
machine you can get into it. You do not need passwds. Some take a little longer
than others. Why make the inevitable harder?
Think about windoze, Windoze requires a passwd for safe/recovery mode. All that
does for me is make me find my CD case, insert the CD into the drive and boot
from the CD. Machine does not have a CD you say OK now I have to go find a CD
drive to plug into the machine and my CD case. There is a passwd on the BIOS
you say, OK now I have to go find the little jumper on the MB to reset the BIOS
to the factory defaults.
The above applies to windoze and Linux. It does not matter. Where there is a
will there is a way.
And let's not forget the old standby of simply removing the hard disk,
attaching it to another system, and getting at any yummy data that way.
Security starts with PHYSICAL security, as any security guru will tell
you. If a system is not physically protected from unauthorized access,
not much else will be very effective.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
4:06 a.m.
And let's not forget the old standby of simply removing the hard
disk,
attaching it to another system, and getting at any yummy data that way.
Security starts with PHYSICAL security, as any security guru will tell
you. If a system is not physically protected from unauthorized access,
not much else will be very effective.
That's a valid point, tought some intruders don't want to steal the
machine or the hard drive, as that would make the attack extremely
evident. Instead, it's easier to break into single-user mode and
create a user account used to remotely access the machine by any other
means.
10:51 a.m.
On Mon, 10 Oct 2005, Felipe Alfaro Solana wrote:
> And let's not forget the old standby of simply removing the
hard disk,
> attaching it to another system, and getting at any yummy data that way.
> Security starts with PHYSICAL security, as any security guru will tell
> you. If a system is not physically protected from unauthorized access,
> not much else will be very effective.
That's a valid point, tought some intruders don't want to steal the
machine or the hard drive, as that would make the attack extremely
evident. Instead, it's easier to break into single-user mode and
create a user account used to remotely access the machine by any other
means.
If it bothers you that much put a passwd on grub. It buys you the same thing.
That way it does not cause extra work for people who do not want/need it.
Regards,
Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com
11:19 a.m.
Felipe Alfaro Solana wrote:
>And let's not forget the old standby of simply removing the
hard disk,
>attaching it to another system, and getting at any yummy data that way.
>Security starts with PHYSICAL security, as any security guru will tell
>you. If a system is not physically protected from unauthorized access,
>not much else will be very effective.
>
>
That's a valid point, tought some intruders don't want to steal the
machine or the hard drive, as that would make the attack extremely
evident. Instead, it's easier to break into single-user mode and
create a user account used to remotely access the machine by any other
means.
Your concern is addressed by using the installer option to setup grub
passwords. The hassle for users while they attempt a recovery seem to
outweight the limited security advantage.
regards
Rahul
1:48 p.m.
On Sun, Oct 09, 2005 at 07:22:43PM -0400, Tom Diehl wrote:
Because requiring a passwd on a box that you can sit in front of and
take
apart is STUPID!!
Invalid assumption; one can have access to the console without having
direct physical access. Think IP-based KVMs, where you can go so far as
being able to power cycle a system without being able to put hands on the
machine. Serial consoles are a similar situation.
Requiring a password for single-user login allows for a breach of KVM or
serial console server security without opening the attached systems to
attack. Grub passwords only solve half the problem (modification or misuse
of the bootloader); single-user passwords prevent the attacker from taking
advantage of a hardware fault (perhaps one that they triggered). Both are
necessary to properly secure the boot process when the console can be
reached over a network or from a shared/less-secured console area.
Granted, this is only an issue for data-center environments generally. I
just wanted to point it out as a use case that I'm familiar with.
--
Edward S. Marshall <esm(a)logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
3:06 p.m.
On Mon, 10 Oct 2005 esm(a)logic.net wrote:
On Sun, Oct 09, 2005 at 07:22:43PM -0400, Tom Diehl wrote:
> Because requiring a passwd on a box that you can sit in front of and take
> apart is STUPID!!
Invalid assumption; one can have access to the console without having
direct physical access. Think IP-based KVMs, where you can go so far as
being able to power cycle a system without being able to put hands on the
machine. Serial consoles are a similar situation.
Well, I will admit I had not thought of that case. :-) In that case they can
still play with grub and bypass the root passwd at boot time, so how does
that help?
I am sure we could argue different corner cases on this forever. :-) I hope
you will agree this is a corner case though.
Requiring a password for single-user login allows for a breach of KVM or
serial console server security without opening the attached systems to
attack. Grub passwords only solve half the problem (modification or misuse
of the bootloader); single-user passwords prevent the attacker from taking
advantage of a hardware fault (perhaps one that they triggered). Both are
necessary to properly secure the boot process when the console can be
reached over a network or from a shared/less-secured console area.
How does a grub passwd not solve the problem. As someone else already mentioned
if you can modify the bootloader you can run init=/bin/sh from the grub command
line and bypass the passwd checks anyway.
Granted, this is only an issue for data-center environments
generally. I
just wanted to point it out as a use case that I'm familiar with.
But in a data center environment you already control who is sitting in front
of the console. If you do not then you have other problems. I will admit that
there are exceptions to every rule but in the majority of cases booting to
RL 1 without a passwd is the least of your problems, if you are worried about
security.
My whole point to this goes back to the original concept of "If you have
physical access to the machine it is not secure" I will argue that a grub
passwd does more to protect from the casual user trying to gain root access,
than requiring a passwd for RL-1. It is just too easy to bypass. If as others
have argued the would be cracker only has access to the console but no access
to the physical machine then a grub passwd or simply disabling
<ctrl><alt><del>
is the way to go. If they can't reboot it they will never see grub to play with
it.
Regards,
Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com
4:07 p.m.
Quoting Tom Diehl <tdiehl(a)rogueind.com>:
Well, I will admit I had not thought of that case. :-) In that case
they can
still play with grub and bypass the root passwd at boot time, so how does
that help?
I am sure we could argue different corner cases on this forever. :-) I hope
you will agree this is a corner case though.
Since there are likely to be multiple such cases, why discount them?
How does a grub passwd not solve the problem. As someone else
already
mentioned
if you can modify the bootloader you can run init=/bin/sh from the grub
command
line and bypass the passwd checks anyway.
If you want to limit the discussion to only machines running grub, then
the argument becomes somewhat easier. But maybe some people want the
docs to pertain to alternative boot loaders also? Maybe not... I don't
know the scope of the doc myself.
But, there is of course always the defense in depth argument. Always use
as many layers of defense as you can. Say they manage to somehow know
your grub password (they watched you type it, it was easy to guess, they
used to be an employee of yours and you didn't change it since they left,
etc). But if they don't also know the root password, then the defense in
depth strategy stops them. Your strategy (rely only on grub) does not
stop them.
But in a data center environment you already control who is sitting
in front
of the console.
No, you don't. Someone can come in (janitor, repair man, someone who was
able to social-engineer his way in, someone who broke in, etc) who isn't
supposed to. And can you really trust all your employees anyway?
If you do not then you have other problems.
We all have problems...
My whole point to this goes back to the original concept of "If
you have
physical access to the machine it is not secure" I will argue that a grub
My whole point is we can make it as secure as possible by using the
security in depth principal, to cover all cases. Sometimes (a university
computer lab) we let people have physical access to the machine, but
we still want to keep them from playing with it as root, to the best
extent possible.
So, we disable the power button, put on a bios password, disable booting
from external media, put a grub/lilo/milo/etc. password on, put a single
user password on, put an alarm on the system that prevents opening the
case without the alarm going off, etc.
Now, what if you *forget* to do one of those? Don't you want a backup
to be there? I'm not perfect, and it is possible someday I might make
a mistake and accidently leave one of the above security features disabled
after working on a machine. I'd like to think that I've got additional
backup security methods in place to help protect me even if I do mess
up one of them. (yeah, if I mess up too many, I'm hosed, but...)
passwd does more to protect from the casual user trying to gain root
access,
than requiring a passwd for RL-1. It is just too easy to bypass. If as others
have argued the would be cracker only has access to the console but no access
to the physical machine then a grub passwd or simply disabling
<ctrl><alt><del>
is the way to go.
But what if an upgrade, or a new admin who doesn't know better, accidently
enables <ctrl><alt><del> on it? What then?
If they can't reboot it they will never see grub to play
with
it.
Uhm, what if they just pull the power cord? Or trip the breaker? Or find
a way to short it out. Or there is a power outage in the building. Or...
Regards,
Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com
--
Eric Rostetter
3:51 p.m.
Quoting esm(a)logic.net:
On Sun, Oct 09, 2005 at 07:22:43PM -0400, Tom Diehl wrote:
> Because requiring a passwd on a box that you can sit in front of and take
> apart is STUPID!!
Invalid assumption; one can have access to the console without having
direct physical access. Think IP-based KVMs, where you can go so far as
being able to power cycle a system without being able to put hands on the
machine. Serial consoles are a similar situation.
Or a machine in a lab, where the machines are on a security loop that prevents
the opening of the case without an alarm going off...
Granted, this is only an issue for data-center environments
generally. I
just wanted to point it out as a use case that I'm familiar with.
There are many others. Once upon a time, almost no unix needed a root
password for single user mode. Then suddenly, most versions added that
feature. Do you think they would add the feature if there wasn't any
reason or need for it?
--
Eric Rostetter
11:12 p.m.
Felipe Alfaro Solana wrote:
>http://www.fedoraproject.org/wiki/SecurityBasics
>
>
If one of the goals of Fedora Core is being secure right from the
start, why is the user allowed to enter single-user without supplying
the root password (sulogin)?
You have no real way to protect someone from getting into to your system
if the intruder has physical access. Such questions come up pretty
frequently. In general, Fedora systems have good defaults where
developers have analyzed and settled upon something or the other. While
we explain security in such documents we need to document the other
potential ways the system can be configured to be secured better and
explain why the defaults are such. Its a given that we want the
defaults to be as secure as possible, so we shouldnt be proactive about
reporting enhancements to make it as such instead of documenting
workarounds wherever possible.
There is a hardening guide languishing in CVS for quite sometime. Its
better to combine the above documents and make it a comprehensive guide.
Security is a huge topic to cover.
regards
Rahul
4:02 a.m.
You have no real way to protect someone from getting into to your
system
if the intruder has physical access. Such questions come up pretty
frequently. In general, Fedora systems have good defaults where
developers have analyzed and settled upon something or the other. While
we explain security in such documents we need to document the other
potential ways the system can be configured to be secured better and
explain why the defaults are such. Its a given that we want the
defaults to be as secure as possible, so we should be proactive about
reporting enhancements to make it as such instead of documenting
workarounds wherever possible.
I agree that having physical access to the machine could make easy for
an intruder to get into it, but sometimes the intruder has limited
physical access, that is, the intruder can't steal the hard drive or
the machine, only sit at the keyboard, restart the machine into
single-user mode and reset the root password (and yes, I know I we can
use a GRUB password).
I think the "you've got physical access, you're lost" sentence is not
a reason enough not to modify "/etc/inittab" and put "sulogin" for
singleuser. Other distros do it and I really appreciate this extra
level of security. It's not usually a burden for a legit sysadmin, and
it makes a little bit more difficult to get root access for non
authorized people.
4:34 a.m.
From: Felipe Alfaro Solana <felipe.alfaro(a)gmail.com>
Date: Mon, 10 Oct 2005 11:02:45 +0200
I agree that having physical access to the machine could make easy
for
an intruder to get into it, but sometimes the intruder has limited
physical access, that is, the intruder can't steal the hard drive or
the machine, only sit at the keyboard, restart the machine into
single-user mode and reset the root password (and yes, I know I we can
use a GRUB password).
If the GRUB password isn't used to protect the machine, the
boot parameter is editable.
In that case, the intruder can alternate "init" program with
/bin/sh, putting "init=/bin/sh" into the boot parameter. It
means that modified /etc/inittab can not protect the machine
because the file is read by /sbin/init (default "init"
programme).
--
SEKINE Tatsuo:
tsekine(a)sdri.co.jp System Design & Research Inst. Co.,Ltd.
7:12 a.m.
On Mon, 2005-10-10 at 19:34 +1000, SEKINE tatz Tatsuo wrote:
From: Felipe Alfaro Solana <felipe.alfaro(a)gmail.com>
Date: Mon, 10 Oct 2005 11:02:45 +0200
> I agree that having physical access to the machine could make easy for
> an intruder to get into it, but sometimes the intruder has limited
> physical access, that is, the intruder can't steal the hard drive or
> the machine, only sit at the keyboard, restart the machine into
> single-user mode and reset the root password (and yes, I know I we can
> use a GRUB password).
If the GRUB password isn't used to protect the machine, the
boot parameter is editable.
In that case, the intruder can alternate "init" program with
/bin/sh, putting "init=/bin/sh" into the boot parameter. It
means that modified /etc/inittab can not protect the machine
because the file is read by /sbin/init (default "init"
programme).
Right. I think the point, Felipe, is that adding a password to
single-user mode gives the admin a *FALSE* sense of security. If you
need that level of security, you need MORE than that amount of security,
if you get my meaning. The only acceptable alternative is to physically
secure the machine. This might be a locked room or a locked rack. If
the security of a machine is a concern, no unauthorized person should be
able to just walk up to it and reboot it.
I would think, however, that this sort of topic, and additional security
measures, could and should be covered in a more comprehensive security
guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe
you should offer to participate with the author to bring this document
up to snuff. As I recall, no editor has yet stepped up to work on it.
Stuart has started some security material on the wiki as well. Instead
of having several efforts floating around in various forms, maybe the
three of you (Stuart, Felipe, and Charles Heselton, author of the
hardening tutorial) can put your heads *together* and work on something
more comprehensive! Three heads are better than one, and all that...
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
7:19 a.m.
I would think, however, that this sort of topic, and additional
security
measures, could and should be covered in a more comprehensive security
guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe
you should offer to participate with the author to bring this document
up to snuff. As I recall, no editor has yet stepped up to work on it.
Stuart has started some security material on the wiki as well. Instead
of having several efforts floating around in various forms, maybe the
three of you (Stuart, Felipe, and Charles Heselton, author of the
hardening tutorial) can put your heads *together* and work on something
more comprehensive! Three heads are better than one, and all that...
I would like to add my few cents but sincerely, I don't know where to
start, or what to do. I have a few recommendations, in form of
firewall rules and sysctl tunable parameters.
11:16 a.m.
Felipe Alfaro Solana wrote:
>I would think, however, that this sort of topic, and additional
security
>measures, could and should be covered in a more comprehensive security
>guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe
>you should offer to participate with the author to bring this document
>up to snuff. As I recall, no editor has yet stepped up to work on it.
>Stuart has started some security material on the wiki as well. Instead
>of having several efforts floating around in various forms, maybe the
>three of you (Stuart, Felipe, and Charles Heselton, author of the
>hardening tutorial) can put your heads *together* and work on something
>more comprehensive! Three heads are better than one, and all that...
>
>
I would like to add my few cents but sincerely, I don't know where to
start, or what to do. I have a few recommendations, in form of
firewall rules and sysctl tunable parameters.
The instructions on getting the relevant docs from cvs and more details
on getting started is available from the project pages
http://fedora.redhat.com/projects/docs/
The docs team is also working on a stage area to build such docs
automatically on a regular basis in the near future. You can also use
the wiki for drafts
http://fedoraproject.org/wiki/Docs/Drafts
http://fedoraproject.org/wiki/WikiEditing
If you need edit group access, register in the wiki and let me know your
username offlist.
regards
Rahul
11:20 a.m.
On Mon, 2005-10-10 at 14:19 +0200, Felipe Alfaro Solana wrote:
> I would think, however, that this sort of topic, and additional
security
> measures, could and should be covered in a more comprehensive security
> guide. As Rahul mentioned, there is a Hardening Tutorial in CVS. Maybe
> you should offer to participate with the author to bring this document
> up to snuff. As I recall, no editor has yet stepped up to work on it.
> Stuart has started some security material on the wiki as well. Instead
> of having several efforts floating around in various forms, maybe the
> three of you (Stuart, Felipe, and Charles Heselton, author of the
> hardening tutorial) can put your heads *together* and work on something
> more comprehensive! Three heads are better than one, and all that...
I would like to add my few cents but sincerely, I don't know where to
start, or what to do. I have a few recommendations, in form of
firewall rules and sysctl tunable parameters.
Feel free to email the authors and discuss with them, or use this list.
The Wiki is a very easy way to contribute; just start by going to
http://fedoraproject.org/wiki/ and make an account for yourself if you
don't have one yet. The important thing is to get involved! That's
what the Fedora community is all about.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
6771
days inactive
6772
days old
18 comments
8 participants
participants (8)
-
Ed Marshall -
Eric Rostetter -
Felipe Alfaro Solana -
Paul W. Frields -
Rahul Sundaram -
SEKINE Tatsuo -
Stuart Ellis -
Tom Diehl