Slashdot Mirror
Red Hat to Release Enhanced-Security Linux
Klatoo55 writes "According to an article by Techweb, Red Hat will release Red Hat Enterprise Linux 4.0, which includes support for Security-Enhanced Linux, in 2005. Red Hat has been running this system with a published IP address asking for hackers to try to break the security. The last version was defeated within 45 seconds, but this new version (apparently to be the policy for the next Fedora) has yet to be cracked."
I think we can bring that baby down without a hack.
What say you slashdot?
45 seconds? Sounds liek someone yanked the power cord out of the boxen to do it that fast...
Eat recycled food - it's good for the environment, and OK for you.
Holy smokes!! If it only took 45 seconds to crack it the last time around, I'd venture to say they overlooked a MAJOR security hole. This one has yet to be cracked; but if they overlooked a major one before, what are the chances that there are several obscure security vulnerabilites they overlooked this time?
-- Stu
/. ID under 2,000. I feel old now.
Has they created something by their own to enhance the security, or is it just that they have included some restricitons to the users/administrators? (ie. have they dissabled the root-account?)
------- In the end there are no begining
I wiped it off my dual-boot machine (now single boot). They do some good things but they seem lost recently. They're scrambling to come up with a successful business model. Unfortunately, I can't wait for them to figure it out. I need a stable linux platform that I can count on.
I hope things work out for them because to a large extent, their success (or lack) will be tied to the Open Source movement.
-- You see, there would be these conclusions that you could jump to
The article implies that SE Linux would be more secure that Windows, especially in light of the MyDoom virus. But doesn't the MyDoom virus depend on a dope sysadmin clicking on a binary attachment to spread?
So how does SE Linux protect systems against trojans?
It's nice to see that SEL is being adopted by someone like Red Hat. I think this development will get more distros and organizations interested in using it, which will benefit the project greatly.
Like it or not, Red Hat sets the tone in many ways, and in this case it's a good thing.
dmiessler.com -- grep understanding knowledge
"... the root had no IP address" presumably should have read "... root had no password" and the jump from the NSA developed SE Linux to the Eclipse IDE escapes me.
Looks like your spellchecker got rooted.
... And if the OS is secure, those vulnerable programs can't do any more damage than they should be allowed to do, even if they do get compromised.
What is the most secure Linux setup? SELinux, grsecurity or something else? Should I ignore these and put every daemon in a separate UserModeLinux jail?
By secure I mean mitigating the likelyhood that any bug will allow an attacker to obtain root, remotely or locally.
Ideally so secure that when properly (and strictly) configured no hole discovered in the past few years would have been exploitable.
This, IMHO, is smart policy. What better way to find the holes in a distro than to co-opt the people most capable of exploiting them? Even at worst this will give the folks at RH a good idea of what exploits are going to be most frequently used against thier systems.
Of course, the security of any system is dependant upon the admin and how he/she configures the software used on the system, but this at least will help to establish a baseline from which to work, and provides full disclosure of any inherent system vulnerabilities to the admins that work with the system.
...as an added bonus, this /. post will see how the system might stand up to a major bandwidth spike....
Don't Panic!
Yes. But exploiting a bug in a particular application or service is only going to expose the data that application or service uses. In a SE Linux system, you don't gain root or system privileges by breaking an application or service since NONE of them run as root.
What happened? Someone ran a brute force root login with the pwlib dictionary or something? Maybe a quick ride with Nessus? Or was it a social engineer who managed to call someone and get the root password?
As has been echoed before time and again -- security is a process, not a product. Of course you'll have more secure products, but it's still up to a competent admin to make sure things are kept secure. Even then, you better have good backups because that one disgruntled guy who works in the mailroom on a machine already inside the firewall just might have an extra ace up his sleeve.
Indeed, this is why we have projects like Hardened Gentoo where SELinux is just one part of it. Other technologies that attempt to make buffer overflows (among other things) very difficult/impossible to exploit is not included in SELinux, nor in Redhat.
In case anyone is wondering, he used the highly reliable Anonymous Coward Benchmarking Suite (TM).
I dig engineering/development efforts that come out and dare people to break their 'stuff'. It takes cahoneys to do such a thing and pretty talented developers to back up such a stance. More power to em!
Don't forget the users - most, if not all, of the fastest spreading Windows trojans and viruses of recent years have relied entirely on user-intervention.
As long as a user can run arbitrary code that opens up network ports and sends data to arbitrary destinations, it will be difficult to completely secure a machine. Per-application egress filtering would go a long way to securing this, but I'm not aware of anything available for Linux that allows you to do so.
It's official. Most of you are morons.
modded "interesting"...not only did people miss the joke, but they actually thought those numbers were anywhere near the truth?
OH MY GOD, all these years, I've been totally blind!!
Thank you for showing me the light. You've changed my life.
Now.. where are those msdos floppies?
What the hell did you pull these number out of?
Copying a 50MB file (not in cache) from one partition to another (on the same harddisk) takes 4.66 seconds, including sync. P-III 500 with regular parallel ATA disk, Linux 2.4.20.
So maybe I've been trolled. Just don't take these guys numbers for anything but shit.
Nope, MYdoom counts on stupid users... yet another reason to license users.
It seems to me that our package managers (used by the majority of Linux users...not everyone compiles from source) are vulnerable to some type of subversion. They are not controlled or vetted by a central authority. There is no 'certificate' which can be attached to them to guarantee their purity. What the Linux community needs, I feel, is a type of central signing authority or cryptographically sealed DRM-compatible package management system. This could eliminate potential threats associated with trojaned Linux packages. Imagine a secure apt-get. Packages would be enveloped in a tough layer of crypt() security. They would be digitally signed by the Debian project manager, or even Ian Murdock for highly critical packages like the kernel. And it would be impossible to accidently load and install a trojan. Apt-get could even be modified to 'phone home' and let the Debian administrators know which packages where the most popular (and make security updating easier!) packages were being installed and to automatically e-mail users with news of package updates and 'special offers' from co-sponsors. I look forward to the community's response!
yes, but a good core OS will limit the damage any 1 program can do... A common argument about windows is that it itself is secure, however the programs that run it(drivers/applications/etc) are insecure. In actuallity, even with a buggy/trojan program being run, a good OS would not allow it to reak havic on much of the system, let alone crash the entire computer.
Hate to feed the trolls but 2.7 isn't even out yet. Making up kernel releases makes you look stupid. On top of that, your numbers are fucking insane.
HAND!
So now Red Hat is using the tired and cliche approach of getting PR by hosting a cracker contest. You would think that they'd have learned from previous examples. Just because a system hasn't been defeated in a cracker contest doesn't mean its secure. Security is a process not something you can shrinkwrap. The proper way to demonstrate the security of a product is through repeated, thorough code audits like some other software distributions are doing. Things must be looking dire indeed for Redhat if they're starting to make announcements of products like this ala another company we know and love.
1. Release OS for years filled with security holes
2. Stop releasing OS for free
3. Sell security based OS
4. ?????
5. Profit!
Mail handling is a good example. Each receive process should be running in a separate jail, with a net connection to the incoming port, a limited connection to the mail database, and no privilege to open files or network connections. Then it doesn't matter what happens in the receive process.
The software that passes data across security boundaries has to be carefully written and audited. But it doesn't have to do much. Software has to be divided into two kinds - big, untrusted programs that do the work, and little, carefully audited security-critical programs that do very little.
The job of the OS is to keep each program in its own security box.
Mail, DNS, and web servers need to be broken up in this way. Now that Red Hat is going with SE Linux, it's time to do this. Get busy.
Red Hat on Security: SELinux
Um, SE Linux
At least it goes a way towards this. Combined with some good iptables rules (possibly dynamic?) you could get a pretty good system.
Executed mail attachments not having access to address book or network, for example.
- Colin
That is five years ago just so you know.
HTTP/1.1 400
Anyone know the IP in question?
Many distributions already use signing for packages. And the stuff about DRM and spyware is blatant trolling; try to be a little more subtle next time.
wtf is a 'Mebibyte'
Was this out of the box security, or after they put up a few firewalls, routers and setup some iptables?
[blue] - The Ministry of Information approved this message...
YHL HAND
even with a buggy/trojan program being run, a good OS would not allow it to reak havic on much of the system, let alone crash the entire computer.
/; sudo rm -rf *".
Ultimately there is no defense against a privileged idiot typing "cd
Oh, sure, if the user doesn't have any administrative privileges, that sort of thing basically prevented, but most of the Windows installations that catch all these email trojans are home setups, not big corporations. I would seriously like to hear someone tell me how a home Linux installation can be made idiot-proof, short of some clueful person giving up a lot of their spare time to do administrative stuff.
All it would take to bring down Fred "The guy in Walmart said Linux was cheaper" would be *one* fake email saying "you have a DEADLY VIRUS; to remove it open a Konsole and type the following [evil] commands, entering your root password when prompted"...
Red Hat discovered that the vunerability in the first version was tied to a switch on the back of the computer. The new version has this in the 'off' position by default.
mebibyte=1024 kibibytes=1024^2 bytes
megabyte=1000 kilobytes=1000^2 bytes
I know you're a fucking troll. I'm criticizing your technique. This is not a 'victory' for you.
i didnt RTFA but the blurb said nothing of compensation if someone did crack it. IF there is a bounty, im sure its not as much as one would make cracking a bank a year from now.
I'll just use my special getting high powers one more time...
No defense? What if the concept of root is eliminated?
Would you like Security-Enhanced or our regular Shitty-Security product?
you took the bait, therefore you LOSE
SMOKE MY COCK, YOU NIGGER
Saying linux is no more secure than windows implies that linux gives no advantages over windows against trojans. By your own argument, this is a false statement.
A true (IMO) statement is "Linux is not much more secure than windows against trojans." This is true in any operating system. Trojans tend to rely on the stupidity of the user, which I venture to say is nearly universal.
As a side note and completely unrelated to the parent, it still amazes me that people with any ounce of knowledge would open an attachment claiming to be an email in binary form. What are you going to do, read a bunch of 1's and 0's?? Come on people!
Ultimately there is no defense against a privileged idiot
Hey! You leave GWB out of this!
Is there any other desktop OS as secure as most Linux distributions? I think not. Hmmm..... there is the Microsoft OS that still has numerous known vulnerabilities, yet still isn't patched.
You obviously don't understand trolling. YOU REPLIED -- the troll WON. YHBT, YHL, HAND.
"In a SE Linux system, you don't gain root or system privileges by breaking an application or service since NONE of them should run as root.
Note that there are really really really dumb users out there (and dumb distro makers) who make the user root (Lindows, others), and thereby make it essentially like windows, taking away user-level security.
Anyway, people should use mandrake because it's superior to lindows et. al.
Long live mandrake!
Wow, impressive. And that without benchmarking with the DOS Server version you probably have.
YHL!
HAND!
King of Swamp Castle: When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. And that one sank into the swamp. So I built a third. That burned down, fell over, and then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Son, the strongest castle in all of England.
replace "castle" with "linux distribution" and it almost makes sense. Kind of. It makes more sense if you also change "swamp" to "red"
-- Having a Creationist Museum is like having an Atheist place of worship
Having SELinux security policies the default security set up is a positively excellent idea. I was hoping some distros would do this (hopefully eventually all), but Fedora is a good start.
SELinux really does make huge strides in securing a system, providing the policy is set up well (for which there are some tools, but a good default from distros will help immensely). Sure, no system is unbreakable, but SELinux is vastly ahead of anything else out there right now. The more boxes out there secured like this there are, the stronger Linux's claims of truly superior security. Windows really does have absolutely nothing even remotely comparable to SELinux right now.
Jedidiah.
Craft Beer Programming T-shirts
2 questions:
Anybody have more info as to why the last machine was compromised in 45 seconds?
Anybody know of a guide for the Linux beginer on how to secure (shutting down services not needed for a desktop machine, in an easy to understand way)a out-of-the-box desktop system??
from: root@redhat
to: groups@l33tscript3rs.org
subject: hack da gibson
Hackable Server, come hack me plz. IP: 127.0.0.1
"But vendors and IT decision-makers widely believe it is too expensive to implement these more hacker-resistant security models, he [Tiemann] said."
So let me get this straight: US industry alone spent around half a billion buckaroonies cleaning up the last little virus/worm fiasco, we get about a half-dozen or so of these little gems per year, and yet it's TOO EXPENSIVE(tm) to engineer in security that would stop this kind of thing from happening?
So tell me, just who are these "vendors and IT decision-makers"? Or, to rephrase the question, just who are these drooling, incompetent, feeble-minded idiots who understand so little about security and the consequences of its failure? I'm asking because I want to make sure that i never, ever use (or heaven forbid, purchase!) any product that they have had anything to do with.
Mr. Tiemann, please tell us, did some people actually say this? Really? Because if so, we need to know which products, companies, and idiots to avoid. And I want some of what they're smoking.
Some already cracked this new one, but since its such an obscure hack, they are waiting till its released and adopted and then they can control the world! (in Slashdot's mind)
Funny this that it`s always a shitload of drunken comments on slashdot on saturday nights.. Wonder why :)
Doolittle :
Bomb no.20 : To explode of course.
Anyone care to share their experiences with SELinux?
come on genious... the chances are low because of how long its remained secure, jackass.
d00d you gots to get your chill on. Just becuase you can't spell properly doesn't mean that it's ok to just post whatever the fuck you want. Have some decency man!
Yeah, I'd have to agree with you there, mostly.
SEBSD (a direct port of the SELinux code) is available for FreeBSD via the TrustedBSD Mandatory Access Control framework. Linux and FreeBSD are both going to kick everyone else's asses in the security department.
There have been exploitable buffer overflows in (going from memory here) PINE, MetaMail and Mutt, all of which in theory could allow a trojan email to be sent to a unix user, and none of which required clicking on an executable.
Are you willing to warrant that there are no such holes in Evolution, Thunderbird or KMail?
News for Nerds. Stuff that Matters? Like hell.
and it's all stuff I've seen before
I don't want to start a holy war here, but I don't get what's with you 17meg file zealots. I have to use a 17meg computer at work, and I am not impressed with it. I've just spent the last 20 minutes trying to copy a 386 from one folder to another. 20 minutes! Meanwhile, at home my 1.44meg file, which by all rights should be a lot slower, can copy a G5 from one folder to another in ten seconds. Emacs lite is grinding to a halt as I type this!
Hey! Bush can't help it if he's a retard! Leave him alone, he's our President!
So does this mean a default Linux install will then be as secure as a default OpenBSD install?
This has been done before (many times, many ways...). Some of this has been said already, but basically, it boils down to a few points:
1) It is not a thorough test of security. People miss things, they take the easiest routes, ignoring more difficult but viable attacks, etc.
2) This is the part that most security people hate: it is often used as a replacement for a real security audit. The script kiddies don't really hold a candle to some of the folks whose time is too valuable to waste on someone's PR stunt. Such folks should be hired directly.
Now then, I checked the article, but I didn't see any mention of real audits of the system. I hope they're not just banking on the NSA name in building it. Yes, the NSA puts out good code, but it doesn't take that much to screw things up... sure it allows fine-grained policies, but you also have to configure and customize those policies to something sensible. If you do it wrong, you either end up with vulnerabilities, or things that don't work right. Neither alternative is good.
So, ummm, wake me up when RedHat talks about who they hired to do a security audits before making their first release version? This is marketing fluff; not something I'd base purchasing decisions on...
#1 programs like cron, login, sshd are still super-trusted, so if you have an openssh hole, you're still fuxed
...)
#2 if you have a kernel bug like mmremap again, you're still fuxed (and the kernel just keeps getting bigger, and bigger, and
This is a very basic run-down for all of you not familiar with SE-Linux.
SELinux was developed orginally by the NSA from code developed at the University of Utah. The idea was to extend the traditional UNIX security model (called DAC, Discretionary Access Controls) in a way to bring Linux up to the level of other Trusted systems and to serve as an example for other systems. They way they did this was to implement hooks into the kernel where modules could directly control the security of kernel. Things like BIBA and other MACs (Mandatory Access Controls) were implemented.
The catch is, to use this feature you have to write a policy spelling out what exactly is and is not allowed. More than likely, the Red Hat people had an oversite in their policy which negated the traditional DAC and other MAC policies. This is similiar to what happens on FreeBSD using ipfw when you deny a given tcp packet with a number like 1500 and then allow the same type of packet on rule 2700. ipfw takes the last match and lets it through. I can see the same type of thing happening with a kernel security policy.
And lighten up. That's the reason Red Hat made the machine public -- they want you to break it. You're doing their job for them. It's a lot cheaper to pay for bandwidth than to pay the salaries of 4 or 5 professional UNIX security people.
It is just stupid to think that having to run chmod +x is security. That is just a protection against stupid USERS, which is not really security at all.
Actually, with SE Linux, the root password *can* be root, and it'll still do you no good. That's the "SE" part....
Oh -- I might add that I have never been hit by a virus or a trojan on any of my Windows systems, despite running with Administrator privileges, because I don't do stupid things (like use Outlook or Outlook Express to read email), and I keep all my antivirus software completely up to date.
The best diplomat I know is a fully activated phaser bank.
-- Scotty.
NSA developed SE Linux ...and they said it's a little better
http://www.nsa.gov/selinux/
Policy based security looks great on paper, but always manages to be difficult to roll-out functionally and securely.
If Redhat was serious about security, they really should consider looking at the work of the PaX project, as well as grsecurity.
Propolice is also another excellent choice.
The mechanisms of protection they offer are a lot easier to deal with on a server, and are quite phenomenal in the amount of otherwise security holes they can plug.
If you have not yet investigated any or all of the above, please do. You will be presently suprised that you can be far more proactive than the "wait and patch" crowd.
I was at EclipseCon and saw his speach. He didn't say that the last "version" was hacked in 45 seconds. He said the "average" time it took to hack a computer without a firewall on the internet (including M$ and *nix) was 45 seconds and that a version of SELinux is on the net with no firewall or root password and it has not yet been compromised.
"So you call this your free contry, tell me why it costs so much to live?" - Three Doors Down
Check out the runas command.
That you don't do stupid things is the most important step, though running as administrator is not not clever either!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
Although the Windows 2000 runas command is a step in the right direction, it is a far cry from the ease of "su - root" and "sudo ...". Take, for instance, if I want to change the IP address in Windows 2000, but I'm logged on as a non-admin user. To do this, I have to kill my user's explorer.exe process before starting up a new one (by typing it into Task Manager's "Create New Task" dialog box) as the administrator. Only then can I get to the Network Properties in the Control Panel with the privledges necessary to change the IP address.
Or just use the netsh command in conjunction with runas.
XP Pro has a group called "Network Configuration Operators" or something to that effect which allows non-admins to perform certain netconfig tasks.
Maybe they just haven't figured out how the rootkit on the new one is stealthed?
Seriously, I don't like seeing products PR'd as 'enhanced security' or having the marketing feebs use the 'this version has not been hacked yet!' slogan as some weird mating call for upper management with large budgets ripe for sucking. The more security-minded things get implemented, the harder it is to get real work done.
New LockD-UP LiNUX. It's so secure, even WE don't know the 10,000 character root password!
I can't recall exactly when, but if my memory serves me at all, I remember reading that Microsoft sought an injunction against the NSA to stop their work on SE Linux. Microsoft claimed that since the NSA is federally (?) funded the taxpayers were basically supporting a competitor to their line of business. I beleive that the injunction was upheld, the NSA had to pull down the SE Linux distro off of their website. I would love to see the NSA (some real wizards at that place) go through Linux with a fine tooth comb and close off any vulnerabilities.
I have never even used SELinux, but unlike many here, have at least taken the time to read up on it. Here is the little I have understood:
SELinux, if set up properly, is secure, and completely bypasses the inferior UNIX security model. You could say:
* Windows is insecure
* Linux is less insecure
* SELinux is almost secure
IN SELinux there is no root account, or at least it has no privilidges -- user's don't have privilidges in this system. So, you can give root to anyone and they won't be able to do a thing. Gentoo have a machine with public root access for just this purpose.
The difference is that each program is banned from doing anything by default. Reading a file, using the network, whatever... The packagers must explicitly assign each program access to what it minimally needs to do it's job.
So Bind (fairly insecure) might be given read access to it's config file, write access to it's cache directory, and port access only for the ports that it needs to listen on. If you then exploit bind it doesn't buy you very much. You can change the cache files, and answer DNS queries, but you can't even change Bind's own configuration, let alone anything else.
You may have the right as an administrator (nothing to do with root) to run bind, but the programs you run do not inherit your privilidges.
As a user, the privilidges that you have depend solely on the roles that you belong to. That's why root is useless, it is a user not a role.
Although there are many security patches for Linux, SELinux seems to me the only truly sound approach to security out there at the moment. If you combined it with hardening solutions designed to minimise the chance of exploits (binary sandboxes) you would end up with a system that is very difficult to exploit in the first place, and once you do manage it it buys you almost nothing anyway.
Although SELinux is built into Linux 2.6, it must be turned on and manually configured before it is useful. This is currently being done for Fedora, Gentoo, Debian, and other serious Linuxes. I believe this will make Linux the most secure general purpose operating system available. Then we really can lord it over the Windows users.
I don't think you have understood what this is about. With SELinux the user's privilidges are not passed to the program, and by default program's have no rights at all. Anyway, if you believe what are you saying, then why don't you go login to Redhat or Gentoo's boxes where they have public root access and see if you can do something bad. It is true that to get the most out of SELinux program's will need to be written specially for it -- simple provable program's with very limited rights, and big buggy programs with no rights at all -- but an SELinux system will already be leauges in front of anything else we have at the moment.
Exactly. This approach can actually work. It's worked before, in some DoD systems not well known outside the military and intelligence communities. (I worked on one of those.)
This is now a communications problem. Most of the literature on this kind of security is too theoretical. We need a "NSA Secure Linux For Dummies" book.
type ? to learn how to use netsh. It's pretty bitchin.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Of course external hacking is relatively easy to stop.
Root exploits (ala Debian's systems getting hosed), and cross file access are more difficult to protect against. You've also issues with Apache, sshd and whatever other third party apps you include.
Folk want auditing of everything, admin security roles, and probably B-level security features too. Prob why Trusted Solaris is always shipped on every other major release - it's a sod to do for a relatively limited market.
man chroot
Thats what a firewall is for. All the unprivilieged ports are blocked to external interfaces on my computer, only accessible via lo.
No, this is not a smart policy, unless you mean for PR. (worked to get a posting on /.)
/. article with posts about the fallacy of cracking contests) and in Secrets and Lies.
Cracking contests have been debunked many times. If no one comes forward and admits to successfully cracking the target, it does not mean that no one cracked it (why blab about it instead of letting the exploitable product go to market with a nice big hole that you already know how to exploit?) If anyone does come forward, that does not mean that all holes were found, only the hole someone was willing to admit to finding.
Bruce Schneier has written quite a bit about the fallacy of cracking contests in Cryptogram (eg. November 2000 and December 1998, which links back to a
The value of the cracking contest (or "hacker challenge") is in the publicity - bragging rights to say, "We co-opted the people most capable of exploiting us and they all failed." As another poster said, this adds nothing to the value an audit.
One word: setuid. Don't be a moron.
Lsof is useful for analyzing a box, but you can simply add the -p flag to netstat -- netstat -ntap -- and see the controlling process. Run this command as root, or netstat will only be able to identify the processes you own.
/etc/rc.d/rcX.d/).
/var/log). You back up your data, right? (If not, you *will* lose your data one day, and *will* be a sad camper trying to rebuild everything you've ever created that you didn't want to spend thirty cents on a CDR backing up). Include your logs in your backup procedure.
On Red Hat, use chkconfig to set which services start at startup (this is nothing more than a pretty frontend to rename a couple symlinks in
The first thing you should do on a new box is run whatever update mechanism your distro provider uses. Apt-get update;apt-get upgrade, yum update, whatever. There have probably been holes discovered. If security is more important than fully tested reliability, I'd automatically run the update sequence through cron nightly.
If you're extremely paranoid, run syslog to a second machine. If your main machine gets compromised, you have a nice log.
Major Linux oopses I've seen before:
* When using X11, never ever use "xhost +". )"xhost +local:" is still asking for trouble.) I don't care how much of a good idea it seems like, *don't fucking use it*. Don't even do it if you aren't on a network and don't think anyone will ever connect to you. This disables all authentication to X11, and at one point a lot of university hackers (old school) used this when they wanted to run a program from another system. Do not do this. If you're running su'ed as root and root can't display a window on the local X11 server due to lack of authorization, use "xauth merge ~[username logged into X]/.Xauthority". That'll just grab the magic authorization cookie for this session from the local user's auth file and hand it to root, so that root can continue to work. Note that recent releases of Red Hat (perhaps due to changes in XFree86, perhaps due to something clever in root's login scripts) seem to authorize root to poke at local displays. Without this, anyone on the Internet with any inclination can sniff your keyboard, dump your screen, send input to your programs, and generally has full privileges of anyone that uses the X server.
* When using X11 programs from a remote system, use ssh and use X11 tunneling. If you don't do so, your keystrokes will cruise over the network unencrypted.
* Use ssh protocol 2 in preference to 1 unless you are damn sure that doing so is not a good idea (or you want to use protocol 2 only). This is probably already default for your site.
The above two points can be implemented by adding the following to your ~/.ssh/config -- this is what I use:
Host *
Protocol 2,1
ForwardX11 yes
* Don't use FTP. We have scp for a reason. FTP sends passwords in plaintext.
* Don't use plaintext mail authentication. Too many people send out their mail password in plaintext. Someone with a 802.11b-capable laptop and sniffer on a college campus can grab *masses* of email passwords from someone's copy of Outlook trying to grab new mail every ten minutes. Most places with a competent mail admin support at *least* support MD5-hashed passwords (which still exposes your email to anyone listening on your network segment, but is better than nothing in that they can't also get your password). I use fetchmail with SSL enabled.
* (not a vulnerability, just a tip) Most Linux distros today are reasonably secure in terms of enabled services out of box. Used to be, in the Red Hat 5.x era, that finger and telnetd enabled out of box was entirely reasonable. Today, however, many folks don't know how to disable services, and so most distributions ship with things off instead of on.
* Archive your logs (generally, the contents of
* This isn't a Linux-specific suggestion, but use gpg. Linux is one of the few platforms with free mail clients
May we never see th
This isn't as common as the ones I've mentioned above, but it's worthwhile in that I suspect fairly security-savvy users might get caught by it (I have, once, in a fortunately benign manner). Windows happens to lock open directories (including those that are current working directories for an application) against movement or deletion. Linux does not do so. 99% of the time, the non-locking this is a really good idea, as the locking has caused all kinds of interesting technical problems. However, access checking takes place at the time one traverses the filesystem into a directory. What this means, among other things, is that if a user has a program with a directory already as its current working directory, and then access control on a parent directory of that directory are changed to prevent a user from entering that directory, the user has already "traversed through" that directory. He will continue to have access, via that program, to the directory in question. So if you decide to remove world access to a directory and then put masses of sensitive files in that directory, and you're a bit paranoid, you might want to run lsof and ensure that nothing already has a subdirectory open.
This usually isn't too bad, but it has an even nastier side effect. *Moving* a directory has a similar effect. If a program moves a CWD into a directory, and that directory is then moved into a chunk of directory structure that the user should not be able to get into, the user can cruise out of the directory and do what he wants with the files on the system.
I ran into this as a rude surprise when I was helping a friend use an FTP server on my system. (Yes, I recommend against FTP use, but it was taking place in a limited environment under closely monitored conditions). I had a directory that he had just entered with his FTP client containing a bunch of files that he was downloading. I moved the directory of stuff back into a subdirectory in my home directory without noticing that he was still logged in and was in the directory with his FTP client. He then went into the parent of the directory he was in. Lo and behold, he had just slipped past my home directory (which had no read or list world privileges), and had free access to all my files. Red Hat maintains a default umask granting read and list privileges to world, probably to make copying files around easy, and so once past the home directory, everything was world-readable and all the directories were world-executable (could be listed).
As I said, this will *probably* not be an issue to most users. However, it is an extremely subtle point that was not immediately apparent to me (and, I suspect, many other people, including security folks with a heavy Windows background). it is very important to any authors of software that might move directories from a world-accessable location to a private location. It is also important to sysadmins that run public UNIX systems.
May we never see th
Here's what the National Security Agency says about Security-Enhanced Linux.
Warez.phantom.com is one of the largest warez archives around. If you manage to get in, there are some phenomenal goodies waiting for you.
;-)
I'd also suggest taking a look at (try pinging, for instance) the following systems:
0x7f.1
There's a pretty good chance that you might even be able to get pings back from the following system:
0177.031415
IP is a wild and hairy world, and we barely touched on name resolution.
May we never see th
But they ARE in the 2.6 kernels
(the buffer overflow protection that is...)
but don't expect me to tell them how I did it.
My brother didn't feel like participating,
but i'm sure he could've done it in half the time
... because it's not. Google on "type enforcement" and get the straight dope.
Cheers,
Earl
Can't wait for the next version of Fedora.
Nice Job - while they are innovating on the security front Microsoft is busy trying to put metadata on your files so you can search better with them - what a joke.
Does this mean they'll actually MD5 the root password?
(Sarcasm-less explanation: During the RedHat installation procedure, the ability to choose to use MD5-encrpted passwords comes *after* you choose your root password, so your root password is encrypted with much weaker encryption until you change it.)
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
My ideal security is an ETDYN and stack-smash-protected executable base, PaX with SEGMEXEC or PAGEEXEC (whichever has the lesser performance hit; SEGMEXEC is good on x86 based 32 bit processors, with a 1% performance hit in my own tests; while PAGEEXEC uses the hardware NX bit on AMD x86_64 CPUs, and thus has no performance hit on those architectures), and john running in the background forcing users to change their passwords when it can crack 'em.
Sure a MAC will protect your system, and it's a good step since it can let you keep root from doing things if someone roots your box; but honestly, the FIRST line of defense is to keep crackers OUT of your box.
Now, if they combine an et_dyn/ssp base with a PaX kernel and seLinux/grsec_acl/rsbac, that I'd consider server-grade security. I've never believed that redhat had any brains, nor any idea what they're doing even if they had brains.
Support my political activism on Patreon.