Tagged as: Linux

yumdownloader --source packagename

The source RPM can be opened with an archive manager and extracted. You can then tinker with it and rebuild a custom new RPM, for instance if you want Apache to be compiled with suexec support built in, which doesn't come standard in any RedHat distro I've ever used.

Note: if you don't have yumdownloader installed, it's part of the yum-utils package. yum install yum-utils.

I've just discovered a program called Console. It's a command prompt replacement for Windows, and is much more like a Linux terminal emulator. Not quite gnome-terminal, but much better than cmd.exe:

Why it's so much better than command prompt:

• It allows you to customize the font and choose any monospace font you have available (I chose DejaVu Sans Mono). Also can select font size, bold, etc.
• It allows you to customize the color palette. Not just the default foreground/background (command prompt allows this), I mean all the other colors. For instance, bright blue and bright magenta look terrible on a black background, so I chose softer shades of these colors (see the screenshot).
• It supports tabs! Not that I use tabs, but it supports them!
• It has a menu bar, toolbar, and status bar by default. I don't like these so I disable them (I disable the menu bar in gnome-terminal too). You can right-click anywhere to get a menu.
• Better copy-and-paste support.
• You can change the transparency of the window, like with Linux terminal emulators. In this regard it behaves like a Linux terminal in a compositing window manager, in that the window is truly transparent and you can see stuff below it. I don't much care for this (I prefer the fake transparency like gnome-terminal uses without a compositing window manager, where it just copies your desktop wallpaper).
• Perhaps most importantly, the window can be resized to any size ya want. With the regular command prompt, the window can be no wider than 80 characters (you can adjust how many characters, but it's still limited to whatever you set and can't be made wider during run-time).

I also recommend OpenSSH for Windows. It installs OpenSSH from the Cygwin project, without the entire Cygwin installation (which is enormous, and is overkill if all you want is SSH from it). With this you can open a command prompt or Console window and use SSH as though you were on a Linux system.

These two programs are all I need to feel more at home when I have to use a Windows system. :)

More interestingly, it warned me that the X Server was running, and that the results might be off a little because the X Server also reads from /dev/console. Apparently /dev/console outputs some binary for all your keypresses, and only root has read access to it (this is probably a good thing). I'm not sure yet what /dev/console binds to, but it seems that whatever your active console (or X session) is, that's what keypresses can be seen there.

If you do `cat /dev/console` as root and type stuff, the terminal prints two binary characters for each keypress. With this one could theoretically make a keylogger. So, out of boredom and to see if I could, I started writing a Perl script to read from /dev/console. For obvious reasons I won't release any code, but for the curious (and those more knowledgeable than the script kiddies)...

I'm relatively sure that the two bytes should be read together as a signed short 32-bit integer. That is, I convert it to decimal and then 4 hex characters by doing this:

my $dec = unpack("S", $buffer);
my $hex = sprintf("%04x", $dec);

It seems that the first byte tends to indicate the key typed on the keyboard, and when converted to decimal shows the same number as showkey does. The second byte might be a modifier on the first byte, for example all four arrow keys send the key code 0xE0 as their first byte, and then the second byte is 0x48 for up, 0x50 for down, 0x4D for right and 0x4B for left.

There's almost no documentation about how to read the binary coming in from /dev/console. I had to look at the source code of showkey.c to get more of an idea. Once I realized that the first byte lines up with the decimal codes given by showkey, that helped a lot. The second byte is weird though: it seems to depend on the character you typed before it. For instance:

1e 9c - Pressed a
1e 9e - Pressed a
1e 9e - Pressed a
30 9e - Pressed b
30 b0 - Pressed b
30 b0 - Pressed b
1e b0 - Pressed a
1e 9e - Pressed a
1e 9e - Pressed a
30 9e - Pressed b
1e b0 - Pressed a

It'd be great if there was actually some documentation about this, but I've discovered a lot about it just from tinkering with it so far.

Unix-like systems do have small amounts of malware out there, but they're more commonly called "rootkits" and they tend to take the form of backdoors and trojans left behind after a hacker has already taken control of your system remotely. Thus they affect server systems more than client workstations. For instance if a server allows root login over SSH, and the root password is weak, a hacker could get into the server and once there installs some rootkits to guarantee further access in the future, even if the sysadmin changes the root password.

For desktop users, the following are commonly cited as to why we're generally safe from viruses:

1) Unix requires executable file permissions before files can be executed.

So for a user to get a virus via e-mail, they'd need to save the attachment to disk, then open its properties and change its permissions to be executable, and then double-click the file to run it (or, if they like the terminal, they'd need to cd to where they saved it, chmod it, and then execute it).

All of this eliminates the issue of accidentally executing e-mail attachments. If a user has to go through this much hassle to run a virus, they're more likely to think about it for a second and wonder how good of an idea it is.

2) Unix generally doesn't give users administrative rights.

Unix-like systems (including Mac) don't do this, and the user that you log on as for your day-to-day use doesn't have permission to do very much. You can download and modify things in your home directory and that's just about it. So, any programs you run are also stuck with these limited privileges. If you download an email attachment, give it executable permissions, and execute it, it's not gonna be allowed to do very much that you yourself aren't allowed.

Can it potentially get your saved passwords out of Firefox? Yes. So I wouldn't recommend trying to run things that are likely to be malicious. But can it affect your system as a whole? Can it get into other users' accounts and get their passwords? Can it infect your boot sector? No, no, no. They need root (administrative) privileges to do any such thing. If a normal user does run a malicious program, it's their own problem. Not like on Windows where it becomes everybody's problem because the system itself has become infected.

3) To do anything administrative, you need to have a password.

On Linux systems the user passwords are typically kept in the file /etc/shadow, and are encrypted using a one-way hashing algorithm. If a hacker has a hashed password, it makes it easier for them to crack it, because it takes out the element of having to go through another system to do so (for instance, brute force login attempts can be handled by the server locking out the account after enough failed attempts). If the hacker has the hash, they can do their own cracking "offline" and only bug the server again once they know the password for sure.

But /etc/shadow is owned and read-only for the root user. So, the regular limited user account that's executing a malicious program doesn't have permission to even read this file, so the program can't even get the hashed passwords out of it.

So to do anything administrative, a password is needed (either the user's password or, more commonly, the root password), and the malicious program couldn't possibly know what those passwords are, and if it were to try guessing, any decently configured system would start to get suspicious of it.

Thus it's highly difficult for a user-executed program to gain root privileges. Sometimes they're able to do it, but they usually need to think way outside the box and exploit security holes in running services to do so. But it's a major hamper in their ability to do any harm.

How Linux viruses could work:

I'm first going to talk about package management systems in Linux. Most mainstream distributions (Fedora, Ubuntu, Mandriva, etc.) have package management systems that control installed software. The distribution's vendor maintains a default repository of available software. The majority of software a user would ever want is usually available in these repositories, from Firefox to OpenOffice all the way to development libraries like GTK+ and GStreamer.

This eliminates the user's need to surf the web and bounce from site to site downloading installers for everything. Most things are available in the software repository, and better yet, they're all cryptographically signed by the vendor, so you can be reasonably sure you're installing trusted, safe software.

But, not all Linux software is available in the repositories. For instance, Sun's VirtualBox. To get VirtualBox you go to its website and download an RPM or Debian package file and install it. To install it, you enter a password (yours, or root's). Then, at least on Redhat-based systems, RPM will complain that the package has not been cryptographically signed using a trusted key, and asks for a second password to be entered to verify that you seriously want to install this.

And this is the point I'm getting at: most Linux software that isn't directly located in one of your trusted software repositories, frankly, can't be trusted. Recent Redhat-based systems give you a second prompt if you attempt to install untrusted software.

So how can Linux viruses be downloaded? If the end user is apathetic and just types in their passwords whenever asked. They could download a package from some random website that appears legit, give their root password to install it, and at that point the package installer has administrative privileges to install that package however it wants.

The package could, for instance, install a binary somewhere, owned as root, and with permissions set in a way that, when executed, it runs with root privileges automatically, regardless of what user executed the binary. And in this way, if it were a virus, it would already have root access to the system, and could do whatever it wanted.

A malicious hacker could take an RPM package such as VirtualBox, replace the main binary with a "wrapper" program (which could launch a second "virus" program and then launch the legitimate VirtualBox binary), repackage it as a new RPM, and post it on a website promoting VirtualBox, saying the download is provided as a convenience to its users so that they don't need to go and download VirtualBox themselves. And since such a wrapper program would launch the legitimate VirtualBox app, most of its users would never know anything was amiss.

So long story short, computers are only as secure as their users are.

P.S. this could also happen to Mac OS X, but it requires less explanation; Mac doesn't have a central software repository full of cryptographically signed packages; they buy or download software the same as Windows users. But they still need a password for installation, so everything after that point still applies. Mac is still a Unix-like operating system.

(On that note, I'm working on researching stuff for a long article I wanna write concerning the sad state of Windows software and the philosophy behind it).

This is one of many cases where after getting into Linux and the open source world, I discovered some free/open source software that does things that I've always wanted to do. In this case, I discovered TiMidity, a MIDI to WAV converter.

TiMidity is used in Linux for support for the MIDI audio format. Rather than have actual hardware drivers to deal with MIDI directly (like Windows does), TiMidity just converts it into WAV format on-the-fly and sends it straight off to your audio hardware. This is its default behavior, anyway. Last night I was digging through its manpages and found out how to save the output as a WAV file instead of sending it directly to the speakers.

Thus, I finally was able to convert MIDI audio to WAV. For reference here's how to do it:

$ timidity -Ow -o output.wav input.mid

WAV files are big and bulky though, so that's where LAME comes in handy. Instead of saving the output to a file, we can pipe it into LAME and save it as an MP3 on the other side.

Thus, here's a one-liner for converting any MIDI file to an MP3:

$ timidity -Ow -o - input.mid | lame - output.mp3

There are Windows ports of these programs available too.

Scene I: The Wall War

[noahp ~]$
Broadcast message from matts (pts/45) (Thu Jul 17 15:45:02 2008):

stop putting crap on this box, we're at 100% usage

Broadcast message from gregc (pts/2) (Thu Jul 17 15:45:50 2008):

Your wall message, dirties my screen

Broadcast message from matts (pts/45) (Thu Jul 17 15:46:08 2008):

good

Broadcast message from joels (pts/37) (Thu Jul 17 15:47:01 2008):

is this how wall works?

Broadcast message from noahp (pts/55) (Thu Jul 17 15:47:23 2008):

People, use /usr/bin/sayto >.<

Broadcast message from benl (pts/72) (Thu Jul 17 15:47:37 2008):

STOP WALLING ME!!111one

Broadcast message from matts (pts/45) (Thu Jul 17 15:47:45 2008):

there is no '*' option in sayto

Broadcast message from noahp (pts/55) (Thu Jul 17 15:48:01 2008):

Where we're going we don't need *'s

Broadcast message from carlof (pts/49) (Thu Jul 17 15:48:12 2008):

looolloololoolllool

Broadcast message from carlof (pts/72) (Thu Jul 17 15:48:13 2008):

oh hai

From: Samy <samy@...>
To: everyone <...>
Date: Thu Jul 17 15:51 2008
Subject: wall

Each time you wall on web11, you're disrupting 12 developers from working and possibly systems team or QA. Don't do this.

[noahp ~]$ wall
Don't be a jerk


Use hud, email, a phone, don't fing use this

The most exciting thing about Fedora 10 for me is that my wireless card works now, just automatically. I installed it on my laptop, logged in, and before my GNOME panels even slid into view, the balloon from the network applet was already visible telling me there were wireless networks nearby. :-D So no longer do I have to fsck with the kernel or use MadWifi patches to get the wireless to work.

Also, Fedora 10 is just really pretty. I actually downloaded a leaked copy of the DVD image the day before it was officially released, to install it in a virtual machine and play around with it (I wanted to wait for it to be officially released so I could verify the sha1sum of the DVD image before installing it on any real PCs). On the virtual machine there was no graphical boot screen, only a text-mode one that had a text-mode progress bar at the bottom. But on my laptop the boot screen was pretty awesome. It had the supernova picture that's part of Fedora 10's theme and it had solar flare animations coming off it.

So, after installing it on my laptop, installing the OpenSolaris GTK+ theme, and tweaking some of my applets and panels the way I like 'em, here's a screenshot:

Current Mood: Excited like omg.

Recently Atheros decided to make nice with Linux and contribute with driver support for Linux. That's cool, except Fedora 9 is all but almost expired and we still have nothing but a hacked Madwifi. In Fedora 10, a built-in kernel module should allegedly have the wireless card work out-of-the-box. But until Fedora 10 is released on the 28th, I'm in limbo.

On my Fedora 9 install I was reluctant to update the kernel knowing that it would break the wireless, especially while the Livna repository didn't have a matching upgrade to the Madwifi hack. But I updated it because there was a matching Madwifi this time, but that made my old (working) kernel 2 versions behind current. So, Fedora installed the new kernel and uninstalled the old one that worked. And, the wireless didn't work anymore with the new kernel.

So, I installed Mandriva Linux. Mandriva is used on the Acer Eee PCs and works heavily with Atheros hardware, and it was known that my particular wireless card works out-of-the-box with Mandriva. And it does. And Mandriva has a pretty default desktop theme. But, it's also a very annoying distro to use.

It's an RPM-based distro, but it doesn't use YUM for its front-end package manager. It uses something called URPMI, which doesn't have a very comparable interface at the command line. That's only an annoyance, but what I have a bigger issue with is how Mandriva replaces standard GNOME utilities with its own "control center" suite, which frankly sucks in comparison.

Mandriva's idea is that they wrapped all system administration tasks -- managing users, hardware, services, software -- into something similar to the Control Panel in Windows. Instead of using the already available, tested and stable GNOME programs, they reinvented the wheel. The most annoying part is that Mandriva's network manager applet really sucks. With GNOME's Network Manager, you can just click the icon on the panel and select the radio box for a wireless network that appears in the dropdown. The applet connects or it doesn't connect and it's really simple and straightforward. Mandriva's system has so much more complexity to it that of course it has bugs.

I can connect to my home network and the network at the office, but many other wireless networks, the applet just refuses to connect to. I click connect and it tells me it's making an effort to do so, but it doesn't, it just sits there forever and ever and doesn't go anywhere. The only way I found to connect is to go into some "Monitor Mode" (some advanced-looking packet monitoring thing that graphs out the network activity) and click some "Connect Wifi" button in there to get the wifi to even connect.

And, I couldn't get the GNOME Network Manager applet to install and work either. Mandriva's custom setup with the network means that the sysconfig scripts for the network devices are dynamically updated by Mandriva's own network program, so that, if I could get GNOME Network Manager to start, it wouldn't be able to find which devices to monitor because anytime I update the config scripts by hand, Mandriva overwrites them again.

Grrrr. I so can't wait for Fedora 10 to come out. >.<