Free t pain software for linux

stephanie is a program for hardening OpenBSD for multiuser environments.

Mmmmm, OpenBSD. Functional, secure, free. With an emphasis on security and integrated cryptography, it carries an excellent reputation for plain old "you-just-cant-hack-this-ness". Not perfect, but nothing is, at least theyre not wearing suits and lying to you.

There are a few roles where i believe OpenBSD fits perfectly. One of these is in multiuser environments, where you have large numbers of possibly malicious users with local access. Here the OpenBSD teams commitment to auditing and fixing code provides a level trust in the environment which is hard to find elsewhere. Also, their efforts to provide integrated cryptography means setting up secure access is easy. So, lets take advantage of the freely available source and tailor it to our specific needs.

Details:

In Phrack 54, route|Mike Schiffman wrote a series of patches for OpenBSD 2.4 for Trusted Path Execution (TPE). Stephanie brings a modified version of these up to speed for OpenBSD 2.8 - 3.0, along with some additional features. A trusted path is one where the parent directory is owned by root and is neither group or other writeable. The TPE works off an internal list of trusted user ids. If a given user tries to execute a file not in a trusted path, and their user id is not in the kernels trusted list, they are denied execution privileges. In real terms, this means they cant download, compile and run krad-sploit.c.

In addition to the TPE, a series of privacy patches came along too. Originally supplied as patches for the individual utilities, these are now implemented through kvm(3), and honour trusted users (ie, trusted users are allowed to see all system information). As a practical example, this means that untrusted users will only be able to see information about processes they own, and the stat tools (netstat, iostat, vmstat, etc) will generally be broken for them. It has been pointed out that by going through trying to kill every possible process id you can find other users processes, but you cant really gain any information on them, so this is not really a great concern.

The original TPE patches had one known way of bypassing the execution restrictions, which was using shell redirection to allow arbitrary interpreted language scripts to be run (perl, sh, etc). This has been fixed up, but could possibly be a big pain in the ass, so please pay attention. When an interpreter is invoked, like most things, it creates a new process group with a job count of one. When a series of commands are connected via the | character on the command line, all the commands belong to the same process group and the job count represents the number of commands eg ps -ax | grep something | awk {print $1} has a job count of three, and the ps, grep and awk processes all belong to the same process group.

The one exception to this is when a user logs in, where we find their shell has its job count set to zero. So how can we use this to prevent shell redirection for a given set of programs? We need to be able to distinguish between ordinary commands and interpreters. At the moment this is done by setting the immutable flag on them. So, in kern_exec(), if we find an untrusted user executing something with the immutable flag set and a job count greater than zero, we flag the process as being potentially dodgy. Then in other system calls we disallow read()ing from fd 0 (stdin) and things like dup2(0, n) if the process has been flagged.

There are two main disadvantages to this. First is the system will need to be brought down to single user mode if the interpreter needs to be patched, and secondly, people will have a hard time suing to an untrusted user. Of course, when a user has shell, they can still type any commands that could otherwise be placed in a shell script, but at the least, this will raise the bar a bit.

Finally, Stephanie brings restricted symbolic links, ala the openwall patches for linux. As time permits, im still working on adding additional features, and will add bits of the openwall stuff i like. The basic goal is to add an extra layer of security without being a monumental pain in the ass to legitimate users, so some things wont be there. I havent added the additional hard link restrictions of the openwall patch, but will do something about this later as time permits.

Installing:

Step by step instructions are presented in the install guide which comes with the source. Read it all first, but its reasonably straight forward. It would be a good idea to read the original article (local copy) if you havent already.

Its distributed under the original two clause BSD license, mess with it all you want, but dont get cranky at me if it breaks something.

You can also read the tpe_adm(8) man page online.

pyGAIM-t is a reworking of the popular GAIM IM client to be based on the Jabber transport, which can connect to any IM system that GAIM can.

HTML::EP is a system for embedding Perl into HTML.
SYNOPSIS
< html >< head >< title >CGI-Env< /title >< /head >
< ep-comment >
This is an HTML document. You see. Perhaps you wonder about
the unknown HTML tags like ep-comment above? They are part
of the EP system. For example, this comment section will
be removed and you wont see it in your browser.
< /ep-comment >
< ep-perl >
# This is an example of embedding Perl into the page.
# We create a variable called time, containing the current
# time. This variable will be used below.
my $self = $_;
$self->{time} = localtime(time());
; # Return an empty string; result becomes embedded into the
# HTML page
< /ep-perl >
< body >< h1 >The current time< /h1 >
Your HTML::EP system is up and running: The current time is $time$.
< /body >
< /html >
NEWS
HTML::EP does now have a homepage, a CVS repository and a bug tracking system. Try
http://html-ep.sourceforge.net/
Have you ever written a CGI binary? Easy thing, isnt it? Was just fun!
Have you written two CGI binaries? Even easier, but not so much fun.
How about the third, fourth or fifth tool? Sometimes you notice that you are always doing the same:
- Reading and parsing variables
- Formatting output, in particular building tables
- Sending mail out from the page
- Building a database connection, passing CGI input to the database and vice versa
- Talking to HTML designers about realizing their wishes
You see, its soon to become a pain. Of course there are little helpers around, for example the CGI module, the mod_perl suite and lots of it more. Using them make live a lot easier, but not so much as you like. CGI(3). mod_perl(3).
On the other hand, there are tools like PHP or WebHTML. Incredibly easy to use, but not as powerfull as Perl. Why not get the best from both worlds? This is what EP wants to give you, similar to ePerl or HTML::EmbPerl. I personally believe that EP is simpler and better extendible than the latter two. ePerl(1). HTML::EmbPerl(3).
In short, its a single, but extensible program, that scans an HTML document for certain special HTML tags. These tags are replaced by appropriate output generated by the EP. What remains is passed to the browser. Its just like writing HTML for an enhanced browser!

AFT is a document preparation system. It is mostly free form meaning that there is little intrusive markup. AFT source documents look a lot like plain old ASCII text.
AFT has a few rules for structuring your document and these rules have more to do with formatting your text rather than embedding commands.
Right now, AFT produces pretty good HTML, LaTeX, lout and RTF. It can, in fact, be coerced into producing all types of output (e.g. roll-your-own XML). All that needs to be done is to edit a rule file. You can even customize your own HTML rule files for specialized output.
Installation
- Run ./configure and then make install.
Enhancements:
aft-html.dat and aft-tex.dat
- Removed the historical hack: using to produce a line break. This was never documented, so it shouldnt cause too much pain to have it removed. If it does cause pain, let me know. You could always use a pragma to (re)implement this feature/hack.
- In the meantime... A new rule element: LineBreak has been introduced so that internal reliance on goes away. LineBreak has not been exposed to the end user (yet).
AFT.pm
- Fixed a small bug concerning line continuations in verbatim mode: Line continuations are no longer parsed when in verbatim mode. What you type is what you should get.

The programming of measurement instruments can be real pain. There are many different protocols, sent over many different interface and bus systems. For every programming language you want to use, you have to find libraries that support both your device and its bus system.
In order to ease this unfortunate situation, the VISA [1] specification was defined in the middle of the 90ies. Today VISA is implemented on all significant operating systems. A couple of vendors offer VISA libraries, albeit mostly in binary form.
These libraries work together with arbitrary peripherical devices, although they may be limited to certain interface devices, such as the vendors GPIB card. Virtual Instrument Software Architecture
The VISA specification has explicit bindings to Visual Basic, C, and G (LabVIEWs graphical language). However, you can use VISA with any language capable of calling functions in a DLL. Python is such a language.
PyVISA project is a VISA binding for Python. In relies on an external library file that you can download from your interface vendors web pages (National Instruments, Agilent, etc). PyVISA implements a convenient and Pythonic access to this library in two layers:
1. First, there is the lower level vpp43, which directly calls the VISA functions from Python. See the PyVISA low-level implementation for more information.
2. On top of it, an object-oriented Python module has been created called visa simply. In case of doubt, use visa because it is easier and more convenient. vpp43 is only for people who need full control or the official VISA functions for some reason. See the PyVISA manual for more information.
Enhancements:
- PyVISA can now cope with older VISA implementations, too.

Luban is a component oriented scripting language. Luban is free and open source. Luban is named after a legendary ancient Chinese civil engineer and carpenter two thousand year ago whose constructions are still in use today.
The programming language spectrum seems crowded. Do we have all the tools we need? The author of Luban likes the scripting languages in general because of their usability. Though he always feels the pain for the lack of suitable component model for scripting.
And he personally considers object oriented scripting is too complicated for scripting purpose and will never compete with C++/Java. He eventually created Luban, a scripting language with a robust component model tailored for scripting purpose. Luban is an easy scripting language that is as clean and manageable as Java.
There have been numerous discussions about software component without clear definition. Lubans definition of component is property based object that is similar to Java Bean. User interacts with component by reading and writing property values, and computation could be triggered by the interactions.
The idea of Luban programming language that scripting language needs a different component model other than conventional class hierarchy to fit its scripting environment. A complete mechanism is built in Luban to define, save and categorize components, which is a fundamental feature of Luban.
Enhancements:
- This release adds the new feature to iterate through the elements in Java container objects.
- The following Java types can now be iterated in Luban: Java array, java.util.Collection, and java.util.Map.

m3u2toc is a Perl script which creates a CD-Text enabled cdrdao TOC file from a XMMS MP3 playlist.

Theres lots of scripts out there to help you burn MP3s as CD audio, but none Ive seen that make a point of writing matching CD-Text data. This script takes the pain out of manually preparing a TOC file with CD-Text author and title data by extracting that info from MP3 ID3 tags.

This script also differs from others by not being an end to end solution for MP3 to CD audio burning. It will take a M3U playlist and produce a TOC file and thats it. Decoding MP3s and running cdrdao to burn them is your job. (Although Ill implement decoding if theres demand for it).

I like small programs that tackle individual problems and solve them well, rather than monolithic ones that try to do everything and fail badly.

Four simple steps to burn:
- complile and save a playlist in XMMS (ensuring ID3 tags are filled).
- set output plugin in XMMS to "disk writer" and decode MP3s.
- run m3u2toc on playlist file to make a TOC file complete with author and title CD-Text data.
- then just run cdrdao using the TOC file and let the CD burn.