Jm4n.com
Home Page for J-Man
J•Man DJ Services can be found Here
Linux Stuff
This page will contain various Linux stuff. I love Linux with a passion,
and am heavily into security on Unix systems in general, and Linux
specifically.
Set-UID Programs
This is the first section on Linux security. I have a major problem with
the number of Set-UID binaries installed by default on most typical Linux
distributions. You may be surprised at just how many programs are set this
way.
One should perform an 'suid audit' on any system, especially if the
system is going to be used as a server, and especially if you will
have multiple users on the system.
It is a pain sometimes to hunt down each suid binary, figure out what it is,
and modify it accordingly. I've found as many as 58 on a RedHat 7.2
default installation, in various locations.
saudit.pl
I created a Perl script to assist me in this. I run this on every box I set
up as soon as I've finished installing all of the system software I plan to
use. I also run it periodically, especially after installing software, to
make sure no new unnecessary suid binaries have been installed.
You can download the script here. You may need to
right-click and choose 'Save Target As', depending on your browser and MIME
type associations...
Update:
I personally had a problem where I accidentally removed the bit from a needed file.
It happened so quickly that I did not remember what file it was. It turned out to
be a required component of qmail, which caused my mail to stop functioning. Not
good!
This prompted me to update the script.
Now, the script logs its actions to saudit.log in the current directory.
It appents to the file, so that you can always go back and see exactly what actions
were taken by the script.
Let me know if you are using the script. I'd like feedback on it -- does it work
well for you? Is there something you'd like to see improved? Let me know! I'm currently finishing up on
a book that will be published, and I'll be linking to this site (after a long-needed
redesign) including the script, so any feedback would be appreciated.
The script is pretty simple, you should be able to figure it out relatively
easily. Simply execute it (you might need to change the Perl intepretor path)
as root, and follow the on-screen prompts.
You can re-run this script any time to do an suid audit. It first searches
out all suid binaries on the system, then prompts you for each one. It displays
the results of a whatis [program name] to help you quickly
identify what the program is and what it does. If that turns up no results,
you may want to switch to another console and type man [program name],
or failing that, do a Google Search for the
command name.
In general, if you don't know what it is, it probably doesn't need to be Set-UID.
However, two files in particular (at least on RedHat 7.x) need to remain
suid:
These are part of the PAM (Password Authentication Module) and I believe they
must remain Set-UID. I am not 100% positive, and will be doing further research
into this...
In a future version, I will add some specific notes on certain binaries, and
I will change the default option to 'N' on certain ones (like 'su' or 'newgrp').
DISCLAIMER
Use at your own risk! I make no warranties on anything. If it breaks your system,
melts your CD-ROM drive, or causes a massive power outage affecting your entire
country, it is NOT MY FAULT. It's just a Perl script, check the source and
do a sanity check before running it (or any script you find randomly on the 'Net)
as root.
Q. Why Perl? Why not Bash or something more universal?
A. Why not Perl? Everyone should have Perl installed. Besides that,
I couldn't have done the script as quickly or pretty in Bash (I'm sure
someone could have, but I couldn't). Plus, I plan to add more
to it later, and Perl just makes that easier for me.
Q. What does Set-UID mean? Why do I need to audit my system?
A. If you are asking these questions, you do not need to be running
this script. Learn what Set-UID means, and make sure you have a solid
understanding of Unix file permissions before running this script.
A future incarnation may be more user-friendly (and newbie-friendly), but at
this time, if you don't know why you need to run it, you don't need to run it.
This script is not intended to replace the need for a knowledgable administrator,
rather, it is here to assist a knowledgable administrator, making this task
easier.
New (9/18/2002): Rant about Linux Audio
Yeah, I do a lot of audio programming. I also do a lot of Linux programming.
So naturally I've run into the serious limitations of audio programming
under Linux.
The first point is this: Linux's current sound system is based on OSS/Free,
which is the limited version of a commercial product. I hate OSS.
I don't mind how Linux has you access the audio device; opening a device
file, and doing a few ioctl()'s don't bother me a bit. But I hate that no
real development goes into the audio system.
Sure, there's ALSA, but I don't personally think this is the way to go. I don't
really want to learn a new API, especially one that I can't expect every user
to have.
Main issues:
I think the level of hardware abstraction needs to be increased. Not that I'm
afraid of low-level programming, rather, there are too many variables. For
example, the amount of audio buffering available depends on which sound card
you have (and thus which driver you are using). All sample format conversions
are done by the driver itself; thus, adding 24 bit support, for example, would
require modifying each driver.
The driver itself should do nothing more than communicate with the hardware.
There should be another layer that then performs sample format conversions,
buffering, etc.
Another issue I have is that Allan Cox is totally against doing sample-rate
conversion within the kernel. I don't personally see why this is such a problem;
I personally have an algorithm that can do it using very, very little CPU (I
can do realtime, arbitrary pitch changing on the I-Opener's 200 MHz chip with
maybe 2-3 percent CPU time used). I don't know if my particular implementation
is unique, though it's possible (I've never seen it used anywhere before...)
Having sample-rate conversion in the audio system has many benefits. Of course
the obvious is if you have a non-standard (or really cheap) sound card. Another
benefit is when playing audio that uses a non-standard or unsupported sample rate.
Finally, some devices (USB to Optical devices specifically) only support one
fixed sample rate, often times 48 kHz. This means you can't play your typical
44.1 kHz MP3 files, unless you pipe it through a converter, or have an MP3 player
that will do so.
Another issue: Try muting the Line-Input, for example, while using it as a
recording source. Unfortunately, muting it also mutes it for recording purposes.
This rules out the possibility of, for example, a real-time DSP application.
The main point is this: we need a new sound system, but one which is compatible
with the current implementation as far as user programs go (as much as is possible anyway), but which offers
better buffering, and more features, than the current system does.
Finally, the ability to mix multiple sound sources is only present in the form
of (several, incompatible and inconsistent) so-called "sound servers".
I *hate* sound servers. This should be handled in the sound system itself.
My proposal is as follows:
- Create an API/interface for audio, which will:
- allow multiple programs to open the "device"
- allow various configuration options, such as a forced sample rate or bit resolution
- transparently mix audio sources
- perform all of the necessary conversions to allow any format of audio to be played properly
- serve as a "wave mapper", routing audio sources to the appropriate sound card (based on configuration)
- have a sane default configuration (as config options would likely require writing to 'files' in /proc)
- handle all buffering, and allow for a large range of buffer size (say up to 3 seconds or more)
- Create drivers, who's only function is to:
- initialize the audio device
- provide the system with information about supported formats
- provide the abstraction layer to allow the sound system to achieve the desired results
With the sample-rate conversions and mixing of multiple sources, this needs
to be done with zero latency (or as close as is possible). Does this mean using
tiny buffers and tons of CPU time? No. It simply means keeping a 'mix buffer'
and knowing exactly where the audio device is at currently, and resetting it
when you need to re-mix the current output buffer -- much like Direct Sound
under Windows. All current cards that I've ever used fully support being reset
without having to close and re-open the device.
I have actually demonstrated this in Linux. My MP3 player does compression
(3 stages, including multi-band), 10-band EQ, normalization, and other
processing. It buffers about 1.5 seconds of audio at a time.
I wanted to be able to have certain functions play a 'beep' sound, but without
a 1.5 second delay. What do I do when it's time to play a 'beep' (or otherwise
mix in a second audio source)?
Step 1: Find out exactly where we are at with audio playback, down to the sample.
Step 2: Reset the audio device via ioctl()
Step 3: Mix in my 'beep' with the current mix buffer, at the appropriate offset (eg, after the last 'played' sample)
Step 4: Immediately dump the mix buffer back to the audio device, resuming playback.
Guess what happens? I get a perfect, seamless 'beep' added to the uninterrupted
music that was playing. It works flawlessly. This method can be used to change the
pitch, volume, etc in real-time, again, much like DirectSound in Windows. Not
that I want to copy Microsoft, but you have to admit, audio in Windows works very
nicely these days, and puts Linux to shame in that area (using Win2k and DirectSound anyway)...
Okay, maybe I will put-up or shut-up here. I am tempted to create said audio
system, rewriting those drivers I can (eg, the ones for cards I own), and offer
guidelines for updating other drivers as well... if I have the time :(
Anyway, I will revise this rant, and clarify/verify some of my statements,
on another day...
DJ and Karaoke Software
•
Audio Editing Sofware
|