I've just finished building a mythtv-based system, and agree with several other posters that hardware choice is absolutely critial.
I'm normally hardware and distribution agnostic, but had very good results with the following combo: * Fedora FC1 * Axel T's apt-rpm of mythtv-suite and ivtv drivers (nothing better than an apt-get install mythtv-suite, and watching it go...) * The following hardware from www.minipc.com.au: * Shuttle SN45G nForce2 Ultra * Athlon 2700+ * 512 Mb 333 RAM * 120Gb HDD, 8MB, Seagate * Mitsubishi DVD +/-R/RW * Hauppauge PVR-350 * Follow the bouncing ball from http://wilsonet.com/mythtv/, http://ivtv.writeme.ch/tiki-index.php?page=TvOutPa l and http://ivtv.writeme.ch/tiki-index.php?page=TvOutHo wto
The shuttle is VERY quiet, and works great with mythtv. Some key 'gotchas' I encountered on the way: * Have the nvidia drivers handy on a CD after installation, or the network card won't work. * Make sure you're date/time is set correctly on your system (several hours stuffing around with TV guide data and XMLTV before I caught the fact that I was 1 year off!) * The Australian default channel positions are often replicated higher up in the spectrum - the 'higher' versions may be the defaults for your area.. I was starting to worry that my tuner card was a dud.
For anyone that wants a one-system mythtv box, I'd recommend grabbing the same specs (probably from the same location if you're in Oz - prices were pretty good for Australia).
We did a fair bit of work on this issue for the Department of Veterans Affairs here in Australia, using winbind/samba. All the kinks are pretty-much out of the system now, and are codified in a document called the 'security configuration guide'.
Email me via our contact page - www dot intersectalliance dot com, and I'll bounce you the contact details for the current DVA security manager - he'd probably be willing to send you a (sanitised) copy of the config guide, which may help you out.
Red.
PDF Converters
on
PDF Writers?
·
· Score: 4, Informative
Prefix everything I have to say with "Nothing is perfectly secure", and keep in mind that poking holes in security concepts is often a lot easier than implementing something effective, efficient, and that makes sense from a business perspective.
Some potential options are: * Authentication / Confidentiality - Application layer - Consider using an authentication scheme for access to portions of your web site - this can be through self-generated X.509 certificates, distributed to your users for example. Such certificates have the advantage of providing both authentication, and encryption at the application layer.
* Authentication / Confidentiality - network layer - A VPN is a step in the right direction I suspect. Something like the openvpn suite may be appropriate. If you wish to use openvpn for authentication as well, you'll probably need to find a relatively secure mechanism to distribute key data.
You may wish to consider making up a 'autorun' CD for each user, which contains the key data, establishes the vpn link, copies the x.509 key to the appropriate location in the users browser config files, and connects to your application. If your end-users are windows machines, it should be relatively easy to automate. If you have unix boxes at the user level, then you may be able to get away with something a little less streamlined.
In this setup, your 'CD' becomes your key. When your user wants to access the 'work application', they pop the CD in their drive, and wait for a connect. You may wish to overlay password access controls on either your openvpn or http server, in order to guard against loss of a CD implying access to your network. In addition, auditing access to your network is a critical (if somewhat difficult) part of your security profile.
Alternatively, you could investigate: * hardware tokens, or SecureID related technology. Many of these systems use usb these days, so there's less of a problem with lack of card readers like there used to be.. It really depends on how much you really want to spend. * Dial up. This is becoming more and more difficult though - often, a user will have a modem and ADSL/Cable link active at the same time, so without additional security controls, you effectively have an uncontrolled gateway to your network.
However, in summary, I'd recommend: * Application level identification (and possibly encryption). Potentially x.509 certificates, or strong passwords. * Network level identification and encryption (potentially something like openvpn, but not using the zero-configuration options) * Some form of effective auditing in lieu of an effective certificate revocation service.
Again... security is very much a marriage of risk, threat, and cost. Some of the above solutions are probabably worth considering in low threat environments, where cost is an issue, and the number of users is easilly manageable. When you have a high threat environment, or where money is not an issue, then a more 'packaged' solution would probably be appropriate.
Although not really capable of providing an audit of reboots (for a variety of reasons, already outlined above), Snare for Linux (google for 'snare') is roughly analagous to the Windows Event log.
Snare is capable of monitoring events such as file opens, execve's, setuid/setgid and so on, which may assist in tracking down the problem.
This, and similar issues, have cropped up at a few of our customer sites over the years. There are situations where bringing in (documents/zip files/spreadsheets/etc.) are an essential part of making organisation function.
Whilst you can implement technical countermeasures to reduce your security risk somewhat, such as installing virus checkers that are able to unzip/unarj/unrar, keeping virus signature definitions up to date, quarantine incoming attachments.. etc, you really need to compare your security risk profile, with the business risk associated with NOT receiving these attachments.
This would normally be the function of your organisational risk assessment - it would compare the likely harm of virus infection, against the loss of capability as a result of not receiving the documents/zip files in question.
Which way you go, really depends on the threat/risk/harm/countermeasure equasion, which is unique to your organisation. However, a quick 'cheat' check: * How badly is it going to hurt your organisation overall, if attachments don't come in? * Do you have the resources to quickly clean up a virus attack if one makes it through?
- If you're a small organisation, with adequate IT staff numbers, and receiving attachments is pretty essential to your normal business... it's probably worth allowing things through.
- If your IT staff numbers are limited such that a virus attack would be a major cleanup effort, or attachments aren't all that critical, then block them, or quarantine them by redirecting them to technically literate help-desk users (who can forward them internally after checking them out).
However, make sure that you make it relatively painless for users to get their files. If you're really anal about things, they'll just open up a hotmail/yahoo/whatever account, ask people to send attachements there instead, and download just like a normal web link.
Sometimes affirmitive action policies are considered neccessary in order to force employers to think outside the box, and consider employees that may not be in the normal "zone of comfort" for the employer in question. Once the bar is raised, and the targetted group is "inside the zone of comfort" once more, the policies could potentially be considered a success.
In order to communicate the SA legislation effectively to other legislators, it shouldn't really be considered a 'statement of preference'.. perhaps it should be referred to as a "software affirmitive action policy".
Let's just take a few lines from the ISC letter, liberally changing "software" references to "people with green eyes" (nods to William Peters classic blue-eyes brown-eyes psychological study). Lets further pretend that green-eyed people are considered to be a "lower caste" by most members of society, and though just as capable as brown, and blue eyed people, are generally not considered equal by employers.
On behalf of the Initiative for eye-colour choice, I write to express our concerns regarding the proposed employment bill, which gives undue preference to people with green eyes, over people with other coloured eyes. The IEC believes that if this "preference" legislation were to be enacted, it would severely limit employment opportunities for South Australia's government, harming not only its citizens, but also South Australia's vibrant government employment sector.
The IEC is a global association overwhelmingly made up of, and supported by, blue and brown eyed people, with over 15,000 members in 89 countries. The IEC strongly supports equal opportunity for people with blue, brown and green eyes, and believe that "preference" policies may not select the most meritorious potential employee in any one project, at the expense of providing equal employment opportunities to green-eyed people.
Sometimes, a government needs to put the good of the many, over the good of the few; and software preference legislation has the potential to level the playing field a little for open source tools, and open-source-related services, in the mind of government project managers.
As a developer of BOTH commercial and open source software, I think there is certainly scope for affirmitive action in software choice.
Now that fairly complex operating systems are starting to appear in special-purpose devices (eg: Cameras, DVD's, Robots, HUD's in Cars), it's not too much of an extrapolation to envisage such an OS controlling critical infrastructure (eg: Traffic lights, Air Traffic Control systems, water purification plant scheduling), or even devices on which life may tangentially depend (eg: Automatic Insulin pumps, Patient vital staistics monitoring systems, etc.)
In situations where a non-special-purpose (read: potentially infectable by viruses) operating system is controlling critical infrastructure, there's certainly potential for the Terrorist label to stick when applied to virus writers.
I've known Paul for a couple of years now. He's a nice enough guy. He's had plenty of political experience as head of Australias 'National Office for the Information Economy' (An IT related government department in Australia), and has also gained some experience by migrating into the commercial world.
ICANN is a pretty big challenge, and it'll be interesting to see how he goes.. but he's certainly got a fair bit of experience behind him that will probably assist him in the role.
The SELinux changes are actually implemented as a 'Linux Security Module', rather than a normal kernel module. Unfortunately this means that you still need to patch your kernel with LSM in order to get SELinux to work.
Both SELinux (which provides security-related access controls) and SNARE (which provides auditing) have been implemented as kernel modules in the past, using the 'system call table' to overlay additional capabilities on syscalls. This made installation VERY simple on most distributions. Unfortunately though, due to the inherant locking problems associated with system call interception on Linux, these tools can't be fully stable on all platforms, while remaining a kernel module.
As such, both projects have had to move away from kernel module functionality towards more direct kernel integration (or LSM in the case of SELinux), which also means moving away from easy installation.
However, the guys at redhat and oracle are making moves towards C2 (or CAPP) complience for linux, so perhaps such functionality may not be so far away after all.
> Ixnay on the estionsquay! They might ind-outfay > about the ecretsay abalcay!
Interestingly enough, with the dept. having one of the highest geeks-per-square-meter counts in government, and with many geeks being avid slashdot readers, "they" should really be "we"!
There will be hundereds of slashdotters in the organisation - not for any dark and shadowy reason, not to spy on Slashdot... but just because they like 'Stuff that Matters'.
In order to get the Tivo working in Australia, Tridge (of SAMBA fame) has created scripts that grab publically available cable and free-to-air channel lists from web sites, and mangles them into Tivo guide data format.
Note that this is only a temporary measure until Tivo set-up shop down-under, and the scripts are not available outside AU (because of the potential to devalue the Tivo service). However, it proves that such a process could potentially be performed for an open-source PVR-like system, based on US listings.
Apart from the well-known Tivo, one project for set-top boxes that springs to mind is the "Video Disk Recorder" project - available from the following site:
http://www.cadsoft.de/people/kls/vdr/index.htm From the "Features" Link:
* Operation entirely via DVB card's On Screen Display and infrared control (LIRC/RCU) or keyboard
* Support for multiple DVB cards (up to four, at least one full featured card with video out required) and "conditional access" (CICAM)
* Channel groups
* EPG display by channel or by time ("What's on now/next")
* Timers: Programming via EPG or manually, priority/lifetime model, single-shot or repeating timers which use EPG subtitle info as recording's title additionally
* Recording storage on disk: Automatically splitting of recording into files (2GB), support for multiple storage directories (may be spread over multiple disks), support for hierarchical storage
* Support for multiple audio tracks and Dolby Digital
* Instant recording
* Playback modes normal, pause, fast forward/backward (multi speed), jump to specific location, jump 60 seconds
* Support for editing recordings (with I-frame accuracy: ~1/2 second)
* Multiple language support
* Support for executing system commands and displaying output on screen
* Network support (SVDRP): Manage timers and recordings via telnet
* Automatic shutdown/wakeup (with certain mainboards)
* Support for automatically executing commands upon recording start/end and editing recordings * Support for MP3/DVD/(S)VCD/DivX playback and DivX recording via patches
Unfortunately, at this stage, LSM doesn't yet have the hooks to support C2-style auditing, although Crispin and I have exchanged a few ideas about this in the past.
For those that need this capability, have a look at SNARE - http://www.intersectalliance.com/projects/index.ht ml
Snare operates by intercepting system-calls at the moment, but the goal is to integrate into LSM in the future.
I can't remember the exact figure, but at a recent Canberra Linux User Group, I was quite surprised at the number of Redhat boxes that a IT team member at ANU mentioned he had deployed (In the hundereds).
I suspect that with this number, things have moved beyond the computer science department.
Quote from a older article:
"The key feature of Linux is that it is very robust as a result. This means fewer crashes and problems than most other operating systems," Mr Bob Edwards, of the Computer Science Department in the Faculty of Engineering and Information Technology, said.
He said the strong background in Linux at the ANU made it an ideal environment in which to become an expert programmer.
"We provide Linux laboratories for students to work on, the staff use Linux and in 2000 we won the Gordon Bell Prize for the fastest Linux machine in the world -- Bunyip," Mr Edwards said. "
ANU - also the home of Tridge from SAMBA, and the Bunyip Beowulf project (http://tux.anu.edu.au/Projects/Beowulf/)
I am beginning to see more and more projects in the Australian federal government that have Linux as either a significant, or supporting, component.
IBM GSA in particular, seem to have really turned around in the last six months or so - from a "We don't have any Linux experts locally" attitude, to a "Let's actively push it" perspective.
"Security" in federal government is often a completely different concept to what would be used in the 'outside world'. When an average Linux user thinks 'security', they consider things like: Open/available source code, patches regularly applied, appropriate file access controls.
For federal government, on semi-closed networks, the word security, when applied to operating systems, generally implies: Good support infrastructure, C2-complient security functionality, the ability to support agency security policy.
It may seem that there is a logical disconnect between these two definitions of security, but with the gradual increase in corporate/government interest in Linux, a gradual accumulation of resources that may directly support government requirements is occuring. See SNARE (Linux C2 audit subsystem - http://www.intersectalliance.com/projects/index.ht ml ) as an example of a project that tries to make Linux more acceptable for organisations like the Federal Govt.
I've only recently grabbed the 'anjuta' IDE (Gnome), and have been pretty impressed so far.
I'm a sometimes user of Visual C++, and although it leaves a bad taste in my mouth... VC isn't a bad development environment. (I refuse, however, to 'upgrade' to the 'visual studio.net' crap).
The ajunta interface is pretty familiar, has most of the VC features that make coding easier, and also has a 'subroutine folding' feature that I love - and haven't seen since my Amiga days. The GDB integration is good - integration of 'run to cursor' is a wonderful thing.
Not sure if it supports Java. http://anjuta.sourceforge.net/ for those that are interested.
My last employer was a high security government organisation that had a real focus on IT - so much so, that we had 6 dedicated operational IT security staff - a number which far outweighs the number normally available in other Australian government departments. (I mean dedicated in both senses of the word - committed, and ONLY working on IT Security)
During a period of increased threat, our primary internet web server effectively became a honey-pot without our consent. There was a great deal of activity in the media surrounding the department in question, and a heck of a lot of interest from the public about the organisation. As such, we believed that the web server would be the subject of significantly more attacks than normal.
We effectively halved our security section during the period of hightened activity - 3 were responsible for the normal IT security tasks, the other three were allocated full time to the task of securing and monitoring the system. We instituted significantly increased network and host auditing (pushing the data out via a one-way data diode to an auditing server, and then onto CD), and put a 'revolving checksum' alert on all web pages (again, sent out via the one-way comms circuit). Any modificatons to the checksum, or any cessation of the 'heartbeat' through the data diode, would set off an alarm in our communications centre, and an operator would literally pull the plug at our firewall to the internet, and call one of the security people. There were also a fair number of host security features enabled on the system - one of which was full C2-level auditing (with about 10,000 lines of perl to provide an intrusion detection facility for the logs).
Sure enough, the level of attacks on our server increased approximately 5 fold. Our logs by the end of 2 weeks were in the multi-gigabyte range, we'd had a couple of false alarms, but no intrusions. We'd provided management with analysis / summary reports for all attacks on the server, including graphical summaries.
So lets just review what it takes to effectively actively monitor a high-threat, high-risk system like the one I've described above: * 3 experienced security staff, normal working hours - conducting audit analysis, extrapolation. * A 24x7 monitoring cell * 1 experienced security staffer, on call 24x7 * Custom development of intrusion detection code (about 4 months worth).
Now I'm not saying that every honey-pot is going to take these sort of resources. But if you want to make effective use of the tool, then you have to be prepared to put the time in. * If you're putting in something someone else has developed, then are you sure there's no EXTRA risk to your system by installing it? (Remember FakeBO?) * Do you have the time to analyse the results of the honey-pot logs? * Is the information going to be of any use to anyone? * Sure you may learn a few tricks here and there, but a majority of your probes are likely to be tradidional nmap/satan/nessus probes, or script-kiddies with the latest cgi scanner. Can the time that you have spent setting up the system be better spent on setting up a small test network, and playing with a few exploit scripts yourself?
There are several grades of security that you need to choose from based on the resources that you have available - and I'd put honeypots right at the end (ie: Security value per resource availability): 1) Patch / monitor security updates. 2) Patch + a network intrusion detection system. 3) Patch + NIDS + firewall log analysis 4) Patch + NIDS + firewall log analysis + host audit. 5) Patch + NIDS + firewall log analysis + host audit + honeypot.
The question that you need to ask yourself is: Am I getting value out of the tool, for the resources I'm putting in. If in your case, the answer is 'yes!', then go for it. But be sure that you know what you want to get out of it first.
Slashdot Mirror
I've just finished building a mythtv-based system, and agree with several other posters that hardware choice is absolutely critial.
a l and http://ivtv.writeme.ch/tiki-index.php?page=TvOutHo wto
I'm normally hardware and distribution agnostic, but had very good results with the following combo:
* Fedora FC1
* Axel T's apt-rpm of mythtv-suite and ivtv drivers (nothing better than an apt-get install mythtv-suite, and watching it go...)
* The following hardware from www.minipc.com.au:
* Shuttle SN45G nForce2 Ultra
* Athlon 2700+
* 512 Mb 333 RAM
* 120Gb HDD, 8MB, Seagate
* Mitsubishi DVD +/-R/RW
* Hauppauge PVR-350
* Follow the bouncing ball from http://wilsonet.com/mythtv/, http://ivtv.writeme.ch/tiki-index.php?page=TvOutP
The shuttle is VERY quiet, and works great with mythtv. Some key 'gotchas' I encountered on the way:
* Have the nvidia drivers handy on a CD after installation, or the network card won't work.
* Make sure you're date/time is set correctly on your system (several hours stuffing around with TV guide data and XMLTV before I caught the fact that I was 1 year off!)
* The Australian default channel positions are often replicated higher up in the spectrum - the 'higher' versions may be the defaults for your area.. I was starting to worry that my tuner card was a dud.
For anyone that wants a one-system mythtv box, I'd recommend grabbing the same specs (probably from the same location if you're in Oz - prices were pretty good for Australia).
Red.
We did a fair bit of work on this issue for the Department of Veterans Affairs here in Australia, using winbind/samba. All the kinks are pretty-much out of the system now, and are codified in a document called the 'security configuration guide'.
Email me via our contact page - www dot intersectalliance dot com, and I'll bounce you the contact details for the current DVA security manager - he'd probably be willing to send you a (sanitised) copy of the config guide, which may help you out.
Red.
Some of these might be useful:
HTMLDoc - http://www.easysw.com/htmldoc/pdf-o-matic.phpn ature - http://freshmeat.net/projects/denature/
e /Word_Processors/PDF/Converters/
Txt2pdf - http://www.sanface.com/txt2pdf.html
html2pdf - http://www.geocities.com/SiliconValley/Lab/5247/
De
csv2pdf - http://freshmeat.net/projects/csv2pdf/
ascii2pdf - http://freshmeat.net/projects/ascii2pdf/
And a google directory reference: http://directory.google.com/Top/Computers/Softwar
Good luck!
Red.
Prefix everything I have to say with "Nothing is perfectly secure", and keep in mind that poking holes in security concepts is often a lot easier than implementing something effective, efficient, and that makes sense from a business perspective.
Some potential options are:
* Authentication / Confidentiality - Application layer
- Consider using an authentication scheme for access to portions of your web site - this can be through self-generated X.509 certificates, distributed to your users for example. Such certificates have the advantage of providing both authentication, and encryption at the application layer.
* Authentication / Confidentiality - network layer
- A VPN is a step in the right direction I suspect. Something like the openvpn suite may be appropriate. If you wish to use openvpn for authentication as well, you'll probably need to find a relatively secure mechanism to distribute key data.
You may wish to consider making up a 'autorun' CD for each user, which contains the key data, establishes the vpn link, copies the x.509 key to the appropriate location in the users browser config files, and connects to your application. If your end-users are windows machines, it should be relatively easy to automate. If you have unix boxes at the user level, then you may be able to get away with something a little less streamlined.
In this setup, your 'CD' becomes your key. When your user wants to access the 'work application', they pop the CD in their drive, and wait for a connect. You may wish to overlay password access controls on either your openvpn or http server, in order to guard against loss of a CD implying access to your network. In addition, auditing access to your network is a critical (if somewhat difficult) part of your security profile.
Alternatively, you could investigate:
* hardware tokens, or SecureID related technology. Many of these systems use usb these days, so there's less of a problem with lack of card readers like there used to be.. It really depends on how much you really want to spend.
* Dial up. This is becoming more and more difficult though - often, a user will have a modem and ADSL/Cable link active at the same time, so without additional security controls, you effectively have an uncontrolled gateway to your network.
However, in summary, I'd recommend:
* Application level identification (and possibly encryption). Potentially x.509 certificates, or strong passwords.
* Network level identification and encryption (potentially something like openvpn, but not using the zero-configuration options)
* Some form of effective auditing in lieu of an effective certificate revocation service.
Again... security is very much a marriage of risk, threat, and cost. Some of the above solutions are probabably worth considering in low threat environments, where cost is an issue, and the number of users is easilly manageable. When you have a high threat environment, or where money is not an issue, then a more 'packaged' solution would probably be appropriate.
Red.
It's not really - the one in the Canberra Botanic Gardens is about twice my height, and it's a young one aparently.
Although not really capable of providing an audit of reboots (for a variety of reasons, already outlined above), Snare for Linux (google for 'snare') is roughly analagous to the Windows Event log.
Snare is capable of monitoring events such as file opens, execve's, setuid/setgid and so on, which may assist in tracking down the problem.
Red.
This, and similar issues, have cropped up at a few of our customer sites over the years. There are situations where bringing in (documents/zip files/spreadsheets/etc.) are an essential part of making organisation function.
Whilst you can implement technical countermeasures to reduce your security risk somewhat, such as installing virus checkers that are able to unzip/unarj/unrar, keeping virus signature definitions up to date, quarantine incoming attachments.. etc, you really need to compare your security risk profile, with the business risk associated with NOT receiving these attachments.
This would normally be the function of your organisational risk assessment - it would compare the likely harm of virus infection, against the loss of capability as a result of not receiving the documents/zip files in question.
Which way you go, really depends on the threat/risk/harm/countermeasure equasion, which is unique to your organisation. However, a quick 'cheat' check:
* How badly is it going to hurt your organisation overall, if attachments don't come in?
* Do you have the resources to quickly clean up a virus attack if one makes it through?
- If you're a small organisation, with adequate IT staff numbers, and receiving attachments is pretty essential to your normal business... it's probably worth allowing things through.
- If your IT staff numbers are limited such that a virus attack would be a major cleanup effort, or attachments aren't all that critical, then block them, or quarantine them by redirecting them to technically literate help-desk users (who can forward them internally after checking them out).
However, make sure that you make it relatively painless for users to get their files. If you're really anal about things, they'll just open up a hotmail/yahoo/whatever account, ask people to send attachements there instead, and download just like a normal web link.
Red.
Sometimes affirmitive action policies are considered neccessary in order to force employers to think outside the box, and consider employees that may not be in the normal "zone of comfort" for the employer in question. Once the bar is raised, and the targetted group is "inside the zone of comfort" once more, the policies could potentially be considered a success.
In order to communicate the SA legislation effectively to other legislators, it shouldn't really be considered a 'statement of preference'.. perhaps it should be referred to as a "software affirmitive action policy".
Let's just take a few lines from the ISC letter, liberally changing "software" references to "people with green eyes" (nods to William Peters classic blue-eyes brown-eyes psychological study). Lets further pretend that green-eyed people are considered to be a "lower caste" by most members of society, and though just as capable as brown, and blue eyed people, are generally not considered equal by employers.
On behalf of the Initiative for eye-colour choice, I write to express our concerns regarding the proposed employment bill, which gives undue preference to people with green eyes, over people with other coloured eyes. The IEC believes that if this "preference" legislation were to be enacted, it would severely limit employment opportunities for South Australia's government, harming not only its citizens, but also South Australia's vibrant government employment sector.
The IEC is a global association overwhelmingly made up of, and supported by, blue and brown eyed people, with over 15,000 members in 89 countries. The IEC strongly supports equal opportunity for people with blue, brown and green eyes, and believe that "preference" policies may not select the most meritorious potential employee in any one project, at the expense of providing equal employment opportunities to green-eyed people.
Sometimes, a government needs to put the good of the many, over the good of the few; and software preference legislation has the potential to level the playing field a little for open source tools, and open-source-related services, in the mind of government project managers.
As a developer of BOTH commercial and open source software, I think there is certainly scope for affirmitive action in software choice.
Red.
Caveat:
Now that fairly complex operating systems are starting to appear in special-purpose devices (eg: Cameras, DVD's, Robots, HUD's in Cars), it's not too much of an extrapolation to envisage such an OS controlling critical infrastructure (eg: Traffic lights, Air Traffic Control systems, water purification plant scheduling), or even devices on which life may tangentially depend (eg: Automatic Insulin pumps, Patient vital staistics monitoring systems, etc.)
In situations where a non-special-purpose (read: potentially infectable by viruses) operating system is controlling critical infrastructure, there's certainly potential for the Terrorist label to stick when applied to virus writers.
I've known Paul for a couple of years now. He's a nice enough guy. He's had plenty of political experience as head of Australias 'National Office for the Information Economy' (An IT related government department in Australia), and has also gained some experience by migrating into the commercial world.
ICANN is a pretty big challenge, and it'll be interesting to see how he goes.. but he's certainly got a fair bit of experience behind him that will probably assist him in the role.
Red.
Well, there's good news, and bad, on this front.
The SELinux changes are actually implemented as a 'Linux Security Module', rather than a normal kernel module. Unfortunately this means that you still need to patch your kernel with LSM in order to get SELinux to work.
Both SELinux (which provides security-related access controls) and SNARE (which provides auditing) have been implemented as kernel modules in the past, using the 'system call table' to overlay additional capabilities on syscalls. This made installation VERY simple on most distributions. Unfortunately though, due to the inherant locking problems associated with system call interception on Linux, these tools can't be fully stable on all platforms, while remaining a kernel module.
As such, both projects have had to move away from kernel module functionality towards more direct kernel integration (or LSM in the case of SELinux), which also means moving away from easy installation.
However, the guys at redhat and oracle are making moves towards C2 (or CAPP) complience for linux, so perhaps such functionality may not be so far away after all.
Red. (SNARE developer)
www.freshnews.org - very handy headline summary site for a bunch of other news sources, including:
slashdot
zdnet
o'reilly network
newsforge
coding style
linux today
freshmeat
bsd today
megarad
techdirt
ars technica
the register
the inquirer
acm
use perl;
madville
linux news
kuro5hin
linux hardware
designtechnica
geeknews
warp2search
icannwatch
neowin
RISKS digest
internet news
wired news
macslash
advogato
tom's hardware
> On another note, I've heard (someone please
> verify) that the military uses explosives to take
> care of old hard drives and storage media.
Depends on the circumstances, and size.
Phosphorous Grenades in some cases (eg: when HD is in a safe).
For operational deployments, some laptops have a 'targetting dot' on them, above the location of the hard drive - ie: 'shoot here'.
Red.
> Ixnay on the estionsquay! They might ind-outfay
> about the ecretsay abalcay!
Interestingly enough, with the dept. having one of the highest geeks-per-square-meter counts in government, and with many geeks being avid slashdot readers, "they" should really be "we"!
There will be hundereds of slashdotters in the organisation - not for any dark and shadowy reason, not to spy on Slashdot... but just because they like 'Stuff that Matters'.
Red.
The Opie mailer supports POP. See http://opie.handhelds.org/
--
Red.
In order to get the Tivo working in Australia, Tridge (of SAMBA fame) has created scripts that grab publically available cable and free-to-air channel lists from web sites, and mangles them into Tivo guide data format.
Note that this is only a temporary measure until Tivo set-up shop down-under, and the scripts are not available outside AU (because of the potential to devalue the Tivo service). However, it proves that such a process could potentially be performed for an open-source PVR-like system, based on US listings.
--
Red.
Apart from the well-known Tivo, one project for set-top boxes that springs to mind is the "Video Disk Recorder" project - available from the following site:
http://www.cadsoft.de/people/kls/vdr/index.htm
From the "Features" Link:
* Operation entirely via DVB card's On Screen Display and infrared control (LIRC/RCU) or keyboard
* Support for multiple DVB cards (up to four, at least one full featured card with video out required) and "conditional access" (CICAM)
* Channel groups
* EPG display by channel or by time ("What's on now/next")
* Timers: Programming via EPG or manually, priority/lifetime model, single-shot or repeating timers which use EPG subtitle info as recording's title additionally
* Recording storage on disk: Automatically splitting of recording into files (2GB), support for multiple storage directories (may be spread over multiple disks), support for hierarchical storage
* Support for multiple audio tracks and Dolby Digital
* Instant recording
* Playback modes normal, pause, fast forward/backward (multi speed), jump to specific location, jump 60 seconds
* Support for editing recordings (with I-frame accuracy: ~1/2 second)
* Multiple language support
* Support for executing system commands and displaying output on screen
* Network support (SVDRP): Manage timers and recordings via telnet
* Automatic shutdown/wakeup (with certain mainboards)
* Support for automatically executing commands upon recording start/end and editing recordings
* Support for MP3/DVD/(S)VCD/DivX playback and DivX recording via patches
--
Red.
Note though, that a facility to support auditing modules (like Snare hopefully!) is being worked on.
m od ule/2001-June/thread.html#897
- see this thread for more information:
http://mail.wirex.com/pipermail/linux-security-
Unfortunately, at this stage, LSM doesn't yet have the hooks to support C2-style auditing, although Crispin and I have exchanged a few ideas about this in the past.
t ml
For those that need this capability, have a look at SNARE - http://www.intersectalliance.com/projects/index.h
Snare operates by intercepting system-calls at the moment, but the goal is to integrate into LSM in the future.
I suspect that with this number, things have moved beyond the computer science department.
Quote from a older article:
- "The key feature of Linux is that it is very robust as a result. This means fewer crashes and problems than most other operating systems," Mr Bob Edwards, of the Computer Science Department in the Faculty of Engineering and Information Technology, said.
ANU - also the home of Tridge from SAMBA, and the Bunyip Beowulf project (http://tux.anu.edu.au/Projects/Beowulf/)He said the strong background in Linux at the ANU made it an ideal environment in which to become an expert programmer.
"We provide Linux laboratories for students to work on, the staff use Linux and in 2000 we won the Gordon Bell Prize for the fastest Linux machine in the world -- Bunyip," Mr Edwards said. "
I am beginning to see more and more projects in the Australian federal government that have Linux as either a significant, or supporting, component.
t ml ) as an example of a project that tries to make Linux more acceptable for organisations like the Federal Govt.
IBM GSA in particular, seem to have really turned around in the last six months or so - from a "We don't have any Linux experts locally" attitude, to a "Let's actively push it" perspective.
"Security" in federal government is often a completely different concept to what would be used in the 'outside world'. When an average Linux user thinks 'security', they consider things like: Open/available source code, patches regularly applied, appropriate file access controls.
For federal government, on semi-closed networks, the word security, when applied to operating systems, generally implies: Good support infrastructure, C2-complient security functionality, the ability to support agency security policy.
It may seem that there is a logical disconnect between these two definitions of security, but with the gradual increase in corporate/government interest in Linux, a gradual accumulation of resources that may directly support government requirements is occuring. See SNARE (Linux C2 audit subsystem - http://www.intersectalliance.com/projects/index.h
Red. (SNARE developer)
I've only recently grabbed the 'anjuta' IDE (Gnome), and have been pretty impressed so far. .net' crap).
I'm a sometimes user of Visual C++, and although it leaves a bad taste in my mouth... VC isn't a bad development environment. (I refuse, however, to 'upgrade' to the 'visual studio
The ajunta interface is pretty familiar, has most of the VC features that make coding easier, and also has a 'subroutine folding' feature that I love - and haven't seen since my Amiga days. The GDB integration is good - integration of 'run to cursor' is a wonderful thing.
Not sure if it supports Java. http://anjuta.sourceforge.net/ for those that are interested.
Red.
During a period of increased threat, our primary internet web server effectively became a honey-pot without our consent. There was a great deal of activity in the media surrounding the department in question, and a heck of a lot of interest from the public about the organisation. As such, we believed that the web server would be the subject of significantly more attacks than normal.
We effectively halved our security section during the period of hightened activity - 3 were responsible for the normal IT security tasks, the other three were allocated full time to the task of securing and monitoring the system. We instituted significantly increased network and host auditing (pushing the data out via a one-way data diode to an auditing server, and then onto CD), and put a 'revolving checksum' alert on all web pages (again, sent out via the one-way comms circuit). Any modificatons to the checksum, or any cessation of the 'heartbeat' through the data diode, would set off an alarm in our communications centre, and an operator would literally pull the plug at our firewall to the internet, and call one of the security people. There were also a fair number of host security features enabled on the system - one of which was full C2-level auditing (with about 10,000 lines of perl to provide an intrusion detection facility for the logs).
Sure enough, the level of attacks on our server increased approximately 5 fold. Our logs by the end of 2 weeks were in the multi-gigabyte range, we'd had a couple of false alarms, but no intrusions. We'd provided management with analysis / summary reports for all attacks on the server, including graphical summaries.
So lets just review what it takes to effectively actively monitor a high-threat, high-risk system like the one I've described above:
* 3 experienced security staff, normal working hours - conducting audit analysis, extrapolation.
* A 24x7 monitoring cell
* 1 experienced security staffer, on call 24x7
* Custom development of intrusion detection code (about 4 months worth).
Now I'm not saying that every honey-pot is going to take these sort of resources. But if you want to make effective use of the tool, then you have to be prepared to put the time in.
* If you're putting in something someone else has developed, then are you sure there's no EXTRA risk to your system by installing it? (Remember FakeBO?)
* Do you have the time to analyse the results of the honey-pot logs?
* Is the information going to be of any use to anyone?
* Sure you may learn a few tricks here and there, but a majority of your probes are likely to be tradidional nmap/satan/nessus probes, or script-kiddies with the latest cgi scanner. Can the time that you have spent setting up the system be better spent on setting up a small test network, and playing with a few exploit scripts yourself?
There are several grades of security that you need to choose from based on the resources that you have available - and I'd put honeypots right at the end (ie: Security value per resource availability):
1) Patch / monitor security updates.
2) Patch + a network intrusion detection system.
3) Patch + NIDS + firewall log analysis
4) Patch + NIDS + firewall log analysis + host audit.
5) Patch + NIDS + firewall log analysis + host audit + honeypot.
The question that you need to ask yourself is: Am I getting value out of the tool, for the resources I'm putting in. If in your case, the answer is 'yes!', then go for it. But be sure that you know what you want to get out of it first.
Red.