In the UK, the computer crime law (the Misuse of Computers Act) criminalises three things, in increasing order of severity:
- Unauthorised access to computer data when you knew or had been told you shouldn't be accessing it (this sort of legal distinction is why some servers have a banner saying "private server, unauthorised access prohibited" or something)
- Unauthorised modification to computer data
- Unauthorised use of a computer with the intention of committing another crime (usually fraud)
This sort of "oops, I've accidentally found a private folder" situation is not a crime, but it becomes one if you carry on looking once you realise you shouldn't be there. This seems like the right compromise to me.
... and DSL/cable users will no longer be hosts on the Internet, in the sense of RFC1122 - the Internet is, after all, peer-to-peer. Since even dial-up users have traditionally been real Internet hosts, that would be a shame.
I would support ISPs blocking incoming connections by default, but only if it's easy to unblock them.
E-mail is a very inefficient way to send large files. There's about 20% overhead.
To be more precise, base64-encoded attachments (i.e. everything except text-based formats like HTML) occupy 33% more bytes, by encoding groups of 3 bytes into groups of 4 ASCII characters.
Attachments are an ugly hack to transfer non-ASCII over SMTP, which is a non-binary-safe ASCII system designed for short text messages (in fact, most of MIME consists of fairly ugly hacks, really).
More recent protocols like HTTP build on MIME in a more useful way and can cope with binaries directly (and HTTP's download-on-demand model and support for partial downloads make it a more sensible way to distribute large files, anyway).
I feel that using fake registration info is fine, as long as it's obvious - something like Mr. Anonymous Unnamed, 123 High Street, Nowhere, Azerbijan is obviously not your real name and address.
Yes, security through obscurity does work, up to a point. The problem is that it's inherently extremely fragile - as soon as someone finds out what's being obscured, your system suddenly drops to no security at all, and you might not even know this has happened.
If it has to be decrypted by the OS when it gets swapped in, it can be decrypted to fish for passwords.... or so you'd think, but remember that swap space is allowed (and expected) to become useless after a reboot. The loop-aes patch for Linux lets you use encrypted swap; on each boot, a new random AES key is chosen and used for the swap partition. The key itself is stored in kernel memory, which (under Linux) can't be swapped and is locked into physical memory anyway.
If you gain root access to the computer while it's still running, yes, you can dig around in the swap partition by retrieving the AES key from RAM, but with root access you could probably rummage around in virtual memory anyway. Most situations where untrusted people could obtain your hard disk involve switching off the computer that disk resides in, which, in the case of loop-aes, would throw away the AES key and render the swap partition illegible.
yes... but you'd think a terminal program would know when some text was selected!!!
It does. It puts it in the primary selection, PRIMARY, just like when you select text in any other X app; middle-click pastes from PRIMARY.
In properly written X apps (e.g. KDE3, but not KDE2, as mentioned above) the Ctrl+C clipboard is CLIPBOARD, not PRIMARY; Ctrl+V pastes from CLIPBOARD.
If you drag over the text "foo" in, say, Mozilla, that puts "foo" in PRIMARY; if you then press Ctrl+C, "foo" is in both PRIMARY and CLIPBOARD. If you click elsewhere to de-select the text, CLIPBOARD will still contain "foo" and PRIMARY will be empty. If you then drag over the text "bar", you have "bar" in PRIMARY and "foo" in CLIPBOARD.
No, that was my point: in a normal app, Ctrl+C copies, but in a terminal emulator (including the Windows equivalents) it doesn't, because that key combo is already taken.
In a Win9x MS-DOS prompt, WinNT Command Prompt, Unix xterm/Konsole, etc., the Ctrl+C key combo already means "interrupt this program", a convention which dates back to dumb terminals and pre-dates the clipboard, so you have to copy and paste some other way.
(To test, on Windows: open a command prompt, ping slashdot.org, wait for a couple of packets to be sent, press Ctrl+C to stop pinging before the usual 4 attempts. Unix ping will keep pinging forever if you don't stop it, which you do with Ctrl+C.)
Most other Ctrl+letter key combos are sent through to the program that's running in your terminal, and at least in Unix, often do something important (Ctrl+W is usually "delete previous word", Ctrl+V sometimes means "insert next character literally", etc., and of course editors like Emacs and Vim use most of the keyboard for *something*) so it's not safe for the terminal emulator to treat any of them specially.
- In MS-DOS Prompt (WinNT Command Prompt too, I think, but I don't have WinNT) you use the system menu or toolbar in a non-standard way (i.e. the method you use is specific to the DOS prompt and doesn't work in any other Windows app).
- In KDE's Konsole you use the Edit menu in a reasonably standard way, but you lose the keyboard shortcut, on the basis that being able to kill a program with Ctrl+C is more important; I don't use GNOME myself, but I assume gnome-terminal behaves similarly.
- In a traditional xterm (or a clone like aterm or rxvt) there is no clipboard support, so you have to use the primary selection (pulled into other apps via middle-click).
Macs don't have the same problem, because they already use Command (the Apple logo/"splat" key) where a Windows user would use Control, so Cmd+C to copy doesn't conflict with the traditional Ctrl+C to interrupt. I seem to remember the terminal emulator on my old Psion 3 had the same property (you conventionally used Psion+C to copy and so on, so Ctrl+whatever was still available, and would send the appropriate character down the serial line).
Yes, there is a common clipboard mechanism. Once you understand that there are two separate clipboards (and that this is a feature), everything makes sense.
Here's how it behaves in modern X environments like KDE 3, GNOME, XFCE, etc.:
- There is a clipboard (called CLIPBOARD in the specs), which you interact with by explicit copy and paste commands, for which the key bindings are conventionally Ctrl+C, Ctrl+V, Ctrl+X to copy, paste and cut respectively. Use it whenever you would use the Windows or Mac OS clipboard, teach it to new users, and so on.
- As an extra "easter egg", applications can manipulate the selection (the currently highlighted text) using the same API. The convention is to select text by dragging (or Shift+cursor keys, etc.) and to copy the selection from another program by pressing the middle mouse button. I will reassert: this is an "easter egg" for advanced users. The specs call this the "primary selection", PRIMARY (there is also a SECONDARY, but I am not aware of any program that uses it).
As documented here: http://www.jwz.org/doc/x-cut-and-paste.html http://pdx.freedesktop.org/Standards/clipboards- sp ec/clipboards.txt
OK, now the holes in that logical explanation:
- KDE 2 used to use Ctrl+C, Ctrl+V to manipulate PRIMARY. This was wrong and had all the flaws the poster cites. Solution: Upgrade to KDE 3, problem solved.
- Some other broken apps do the same. Solution: either fix them as you suggest, or stop using them. GNU Emacs 20 was apparently broken in the same way as KDE 2, while XEmacs and GNU Emacs 21 apparently work in the same way as KDE 3 (I can't confirm this, I use vim myself).
- Some (usually older) apps (like xterm) don't have copy or paste commands at all, but do have the selection/middle-click behaviour. Solution: either use something else (e.g. Konsole if you're a KDE fan) or learn the middle-click behaviour too. Since the command line is generally considered to be "hard", it shouldn't be that much of an intellectual leap.
- Ctrl+C already means something very common and specific (send a SIGINT) in console windows, so the standard Windows-style keybindings cannot be used in console windows. This is a historical clash between the Unix/DOS "Ctrl+C interrupts" and the Windows/OS2 "Ctrl+C copies" (on the Mac the convention is actually Command-C, so Ctrl is still available, and OS X's Terminal uses it as you'd expect) - Windows' MS-DOS-derived command prompt has the same conflict and a similar solution.
Version "numbers" aren't conventionally decimal numbers, at least in the Unix world; instead, you split the version up at the dots and compare succesive components, so 4.10 comes between 4.9 and 4.11, 4.100 is the version after 4.99, and so on. As a number, 4.10 would usually denote "four point one zero", but as a version number it's "four point ten" (or even "four dot ten", I suppose).
It looks less strange in a version numbering scheme with three or more components (Linux 2.4.26, Perl 5.8.1, Apache 1.3.20) where it's obvious that you're not dealing with decimal numbers. It's also consistent with the way sections are numbered in many textbooks, RFCs, W3C standards, etc. (chapter 1 section 2 would be headed "1.2", its subsection 20 would be headed "1.2.20".)
Most projects' second (minor) version number never reaches 10, since there's a new major release at least once every 10 minor releases (e.g. Apache 1.3 followed by 2.0, or Debian 2.2 followed by 3.0).
(A few projects do use decimal numbers: Perl used to, so the version before Perl 5.6.0 was something like Perl 5.00503, which would be Perl 5.5.3 in the new system.)
Meh, should have used preview. I of course meant to say that there are three problems on the Mac.
(Nobody expects the MacOS Security Omission! Our two exploits are confused security boundaries, sloppy implementation and silly internal... no. Our three exploits are confused security boundaries, sloppy implementation, silly internal protocol handlers and an almost fanatical devotion to Steve Jobs... oh, I'll start again.)
Once my exams are over, I plan to look through the KDE ioslaves (at least the common ones in kdebase, kdenetwork etc.) and check what standards they comply with, and whether they appear to be exploitable. I'm not a security expert, but hey, many eyes, right?
There are two problems on the Mac:
- Auto-registering protocols from all mounted images, while having URLs that mount a disk image with no user interaction.
Apple need to decide where to put the security barrier - either mounting a.dmg is an expression of trust by the user, in which case Apple should never do it automatically (or at least have an unavoidable prompt before mounting remote.dmg files), or it's not, in which case newly mounted.dmg files should be considered to be untrusted and shouldn't be able to autorun anything. (Or both, of course.)
- Some protocol handlers are mis-implemented, like the telnet one which accepts telnet:-nfoo (or telnet://-nfoo?) as a request to telnet to the host -nfoo, but naively invokes telnet with the argument -nfoo (which doesn't do what you want).
If Mac OS X telnet used GNU-style arguments, invoking telnet -- -nfoo would be sufficient to get the desired behaviour, but since it presumably doesn't, the telnet: protocol handler should be responsible for filtering out harmful hostnames.
(I observe that a non-GNUish telnet will be unable to connect to certain hosts via command-line arguments: if you actually have a host called -nfoo, it appears that at least Debian's Netkit telnet can only connect by running with no host parameter and instead using the command "open -nfoo")
- Silly internal protocol handlers which are hopelessly non-standard and may not have been designed with security in mind (help:, disk:, afp:, and so on). These "URLs" are also nowhere near as Universal as they claim to be.
KDE isn't any better in terms of number of nonstandard URI handlers, although I hope theirs are actually secure. On my computer, the Protocols page in KDE Info Centre lists the non-standard schemes about, ar, audiocd, bzip, bzip2, camera, cgi, devices, fish, floppy, fonts, ghelp, gzip, help, info, mac, man, metainfo, nfs, print, printdb, programs, psion, rdp, settings, system, tar, thumbnail, vnc, webcal, webdav/webdavs and zip; I'm not sure about the standards status of mms, mrml, rlogin, rtsp, sftp, sieve or smtp/smtps either.
At a quick glance, cgi: doesn't look like the most secure protocol imaginable, although it appears to only allow arbitrary program execution from folders nominated by the user (a list which defaults to being empty, at least on Debian), so it might actually be OK despite appearances.
It's a limitation of the Unix user model (and probably also the Windows user model) that only root can change userID to become a less priviledged user (programs like su, sudo, ksu, etc. are all setuid root, or at least communicate with something that is, in order to accomplish this). Making a program that can switch UID thus requires setuid bits and other unpleasantness, and requires active intervention from root.
(It's particularly nasty if you want to avoid active attacks rather than just mistakes, because you then have to ensure that you've irrevocably changed UID and that there's no going back - looking at Linux man pages, there are some unwelcome interactions between real, effective and saved UIDs, and between BSD and POSIX semantics.)
It would be nice to have some feature where there's a hierarchy of users, either hard-coded (e.g. a user fred can setuid() to any user whose name starts with fred-, but the sub-users can't setuid() back), or, better, dynamically defined by root (e.g. by writing something into/proc or/sys, which you'd normally want to do during boot).
I might see if I can implement this after my exams finish: "Feudal Linux", perhaps?
Idle musing about what I'd want to happen, assuming that fred-www is a sub-user of fred: - if a file's permissions let fred-www read or write it, so can fred - if fred-www can traverse a directory, so can fred - fred can't execute fred-www's files? Fairly useless in practice, since the problem is more likely to be with scripts, plugins etc., in which case it's the application's responsibility to protect users from accidentally executing other users' files - fred can send signals to fred-www's processes (so kill/xkill still work, for when the browser crashes or uses excessive CPU time), but not vice versa (because otherwise fred-www could be extremely annoying) - root (or, looking at kernel/sys.c, anyone with capability CAP_SETUID) implicitly has everyone else as a sub-user
Of course, this idea is partly inspired by the vapourware/semi-hoax project Jesux (I don't agree with the goal, but that doesn't mean they can't have good ideas:-)
(Alternatively, User-mode Linux could be an idea to look into.)
You assume that because the demo page can't do commands containing spaces, you're immune to commands containing spaces. Unfortunately, if an attacker can get a program of their choice placed at a location of their choice using an auto-mounted DMG file, they could write and compile, say, a shell script, or a C program which does the equivalent of "rm -rf/".
That aside, further nitpicking:
I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix trick to prevent one from deleting their whole directory by accident.
If the attacker can't use command-line args, you're probably OK there:
smcv@linuxbox:~/foo$ rm
rm: too few arguments Try `rm --help' for more information.
If the attacker does "rm *" in your $HOME, yes, a file called "-i" could save you. None of these would be stopped, though: rm -rf/, rm -rf $HOME, rm $HOME/*, rm./*, or even (if MacOS X's rm implementation has GNUish command-line options) rm -- *.
Another method is to have "alias rm rm -i" in your.cshrc or.tchrc environment configuration.
Everything *you* run in an interactive csh or tcsh has that run first. If a malicious program is run through/bin/sh or just exec'ed directly (both are much more common ways to launch a program), csh isn't consulted. (The various variants of csh are designed as interactive shells; whatever you use for interactive use,/bin/sh is the standard noninteractive shell for scripting, and often also the interactive shell (e.g. on Linux, the interactive shell is usually/bin/bash, and/bin/sh is usually also bash).)
In OS X, admin users have write access to/Applications even when not sudo'ed to root (to enable drag-and-drop installs), so it's possible to install many apps without using any priviledges. If the same user does "rm -rf/", those apps will disappear too.
If you want to kill your hidden config-files, try this:
rm -rf ~/.*
You can view these files like this:
ls -al ~/.*
The first will give you some error messages when it attempts to delete ~/. and ~/.., which are/Users/foo and/Users (assuming your home directory is the OS X default/Users/foo). The second will not show you what you expect either.
The correct shell-glob pattern is probably ~/.[^.]* ([^.] means any character that isn't a dot). That will miss files called silly things like..myfile; if you have such files, which you probably shouldn't, a pattern like ~/.[^.]* ~/..?* will notice them too.
To list hidden files, just doing "ls -a ~" or "ls -A ~" is simpler (I don't know whether -A works in OS X's BSD ls, but in GNU ls it's an alias for --almost-all, which shows everything except "." and ".."). As usual, add -l if you want the long-format listing.
IM2000 does sound like a good idea; it's basically the way I send inconveniently large attachments, in fact (zip, upload to temp directory on web server, send an email "covering note" with the URL, ask recipient to let me know when they've downloaded the file so I can delete it).
The immediate down side I can think of is that the sender knows (by observing their web server logs) that you received and read that message (or at least that you received it with a POP3-equivalent offline mail reader, which would presumably just have to download everything that wasn't blacklisted). This is possibly a good thing (debatable) if it's legit email, but is a bad thing if it's spam (the spammer now knows that joe@joe.com is a valid address which is read by a human).
Sorry, as far as I know, each model of Mac is only compatible with Airport *or* Airport Extreme (the expansion cards are different shapes or something stupid like that, I think) - titanium Powerbooks like mine can only use Airport non-Extreme (Hermes/Orinoco-based 11b chipset and well supported in Linux), the newer aluminium Powerbooks can only use Airport Extreme (based on Broadcom 11g chipset, no Linux drivers).
For recent Mac hardware in 2.4, you should apply a recent "benh" kernel patch to the appropriate version (in the current Debian unstable, kernel-patch-2.4.25-powerpc is the benh patch, and kernel-tree-2.4.25 provides the corresponding source; the precompiled PowerPC kernels are also compiled with this patch). Ben Herrenschmidt is one of the main Power Mac Linux developers.
Apparently Linus started using a Mac sometime during 2.5/2.6 development, so this patch is merged in 2.6.
I have a 12" G4 laptop DVI. I want linux, with suspend. Can't do that on the powerbook.
Actually, you probably can. Debian unstable works fine for me on a 15" Titanium Powerbook (the 1GHz one with DVI), and as I've commented above, suspend-to-RAM is fine (just install pmud and run it in the background; to sleep, close the lid or run/sbin/snooze).
Unfortunately, the more recent Powerbooks have Airport Extreme, which isn't supported under Linux (because "Airport Extreme" cards are based on Broadcom chipsets, and Broadcom are extremely unhelpful), but if you're just running open-source and you can live with a slower 3D card than you mentioned (Radeon M9, which is the Mobility version of a Radeon 9000 I think), the same model Powerbook I have sounds ideal; you could try to find one second-hand.
The only component in my Powerbook that I know won't work with open-source drivers is the modem, and I can't say I've ever really wanted to use that anyway; I'm not sure about TV-out and DVI-out, but VGA-out certainly works, and I'm told the Firewire port should be OK too.
(The XFree86 Radeon driver is open-source and has at least some 3D acceleration, although I'm not sure whether it uses the card's full capabilities - it might not do full T&L or something. ATI has a more capable driver, but it's proprietary and they've only released it for x86.)
Bogomips *are* an objective measure, though. They're how many million times per second Linux can run a particular busy-loop, used for high precision timing (basically the same idea as how you did delays in old BASIC programs, i.e. FOR X%=1 TO 100000:NEXT X%, adjusting the large number down if you had a slow computer, or up if you had something blindingly fast like the 1.8MHz 6502 in a BBC Micro; ah, those were the days:-)
In other words, they're an objective measure of how fast your CPU can achieve absolutely nothing, hence the name bogomips (= millions of bogus instructions per second).
Old x86s generally do about a bogomip per MHz, newer ones (Pentium and up) do 2 bogomips per MHz due to different pipelines and such, so yes, they really *can* do twice as much nothing per clock cycle.
Of course, how fast a CPU can spin round and round a redundant loop has little relation to how much actual work it can do, so the only things bogomips are useful for are high-precision timing and pointless boasting.
(Different CPU architectures run different busy-loops in that part of the kernel, so in any case bogomips aren't directly comparable between architectures anyway. My G4 manages a little less than one PowerPC-bogomip per MHz.)
Personally I would say Linux is a good year from this level of sleep mode, but then I don't follow kernel dev too closely, so who knows.
Linux on x86, perhaps, but that's at least partly a hardware/APM/ACPI issue; PCs have historically had big problems with any sort of sleep mode, regardless of OS. Linux on Mac hardware, on the other hand, has much the same suspend-to-RAM behaviour as MacOS.
I've used Linux 2.4.2x and 2.6.5 on my Powerbook; both do pretty much what you said, but they're slower to sleep and wake up than MacOS (about 3 seconds to sleep and 1 second to wake up, while MacOS takes about half those times), and sometimes accidentally wake up when I plug in cables while they're asleep (USB mouse, power lead, network cable). Both of those differences are just trivial annoyances that waste a few seconds now and then, rather than anything serious.
To put the Powerbook in sleep mode you either run/sbin/snooze (no special priviledges necessary) or just shut the lid. Both are handled by the Mac/PPC power management daemon, pmud.
I glanced through the one for the DVI Powerbook G4 before the database ran out of filehandles and died; their photos for access to the underside of the Powerbook show the it with the keyboard/other components removed and the screen closed over the top, which I'm not convinced is a good idea (if something falls through the gap where the keyboard should go and onto the screen, it'll get scratched).
The Apple manual for the same model suggests putting the keyboard/wrist rest area of the laptop flat on a desk (with a towel or similar underneath), with the screen open and extended off the desk into your lap; that strikes me as less likely to get the screen damaged.
Slashdot Mirror
In the UK, the computer crime law (the Misuse of Computers Act) criminalises three things, in increasing order of severity:
- Unauthorised access to computer data when you knew or had been told you shouldn't be accessing it (this sort of legal distinction is why some servers have a banner saying "private server, unauthorised access prohibited" or something)
- Unauthorised modification to computer data
- Unauthorised use of a computer with the intention of committing another crime (usually fraud)
This sort of "oops, I've accidentally found a private folder" situation is not a crime, but it becomes one if you carry on looking once you realise you shouldn't be there. This seems like the right compromise to me.
... and DSL/cable users will no longer be hosts on the Internet, in the sense of RFC1122 - the Internet is, after all, peer-to-peer. Since even dial-up users have traditionally been real Internet hosts, that would be a shame.
I would support ISPs blocking incoming connections by default, but only if it's easy to unblock them.
E-mail is a very inefficient way to send large files. There's about 20% overhead.
To be more precise, base64-encoded attachments (i.e. everything except text-based formats like HTML) occupy 33% more bytes, by encoding groups of 3 bytes into groups of 4 ASCII characters.
Attachments are an ugly hack to transfer non-ASCII over SMTP, which is a non-binary-safe ASCII system designed for short text messages (in fact, most of MIME consists of fairly ugly hacks, really).
More recent protocols like HTTP build on MIME in a more useful way and can cope with binaries directly (and HTTP's download-on-demand model and support for partial downloads make it a more sensible way to distribute large files, anyway).
There's no css for scale to 1200 and fix it at wider screens.
The standard answer to CSS complaints: actually, there is, it just isn't implemented in Internet Explorer. The following CSS
div.main-content { max-width: 1200px; }
does exactly what it says on the tin (constrain width to 1200 pixels).
I feel that using fake registration info is fine, as long as it's obvious - something like Mr. Anonymous Unnamed, 123 High Street, Nowhere, Azerbijan is obviously not your real name and address.
Yes, security through obscurity does work, up to a point. The problem is that it's inherently extremely fragile - as soon as someone finds out what's being obscured, your system suddenly drops to no security at all, and you might not even know this has happened.
If it has to be decrypted by the OS when it gets swapped in, it can be decrypted to fish for passwords. ... or so you'd think, but remember that swap space is allowed (and expected) to become useless after a reboot. The loop-aes patch for Linux lets you use encrypted swap; on each boot, a new random AES key is chosen and used for the swap partition. The key itself is stored in kernel memory, which (under Linux) can't be swapped and is locked into physical memory anyway.
If you gain root access to the computer while it's still running, yes, you can dig around in the swap partition by retrieving the AES key from RAM, but with root access you could probably rummage around in virtual memory anyway. Most situations where untrusted people could obtain your hard disk involve switching off the computer that disk resides in, which, in the case of loop-aes, would throw away the AES key and render the swap partition illegible.
yes... but you'd think a terminal program would know when some text was selected!!!
It does. It puts it in the primary selection, PRIMARY, just like when you select text in any other X app; middle-click pastes from PRIMARY.
In properly written X apps (e.g. KDE3, but not KDE2, as mentioned above) the Ctrl+C clipboard is CLIPBOARD, not PRIMARY; Ctrl+V pastes from CLIPBOARD.
If you drag over the text "foo" in, say, Mozilla, that puts "foo" in PRIMARY; if you then press Ctrl+C, "foo" is in both PRIMARY and CLIPBOARD. If you click elsewhere to de-select the text, CLIPBOARD will still contain "foo" and PRIMARY will be empty. If you then drag over the text "bar", you have "bar" in PRIMARY and "foo" in CLIPBOARD.
No, that was my point: in a normal app, Ctrl+C copies, but in a terminal emulator (including the Windows equivalents) it doesn't, because that key combo is already taken.
In a Win9x MS-DOS prompt, WinNT Command Prompt, Unix xterm/Konsole, etc., the Ctrl+C key combo already means "interrupt this program", a convention which dates back to dumb terminals and pre-dates the clipboard, so you have to copy and paste some other way.
(To test, on Windows: open a command prompt, ping slashdot.org, wait for a couple of packets to be sent, press Ctrl+C to stop pinging before the usual 4 attempts. Unix ping will keep pinging forever if you don't stop it, which you do with Ctrl+C.)
Most other Ctrl+letter key combos are sent through to the program that's running in your terminal, and at least in Unix, often do something important (Ctrl+W is usually "delete previous word", Ctrl+V sometimes means "insert next character literally", etc., and of course editors like Emacs and Vim use most of the keyboard for *something*) so it's not safe for the terminal emulator to treat any of them specially.
- In MS-DOS Prompt (WinNT Command Prompt too, I think, but I don't have WinNT) you use the system menu or toolbar in a non-standard way (i.e. the method you use is specific to the DOS prompt and doesn't work in any other Windows app).
- In KDE's Konsole you use the Edit menu in a reasonably standard way, but you lose the keyboard shortcut, on the basis that being able to kill a program with Ctrl+C is more important; I don't use GNOME myself, but I assume gnome-terminal behaves similarly.
- In a traditional xterm (or a clone like aterm or rxvt) there is no clipboard support, so you have to use the primary selection (pulled into other apps via middle-click).
Macs don't have the same problem, because they already use Command (the Apple logo/"splat" key) where a Windows user would use Control, so Cmd+C to copy doesn't conflict with the traditional Ctrl+C to interrupt. I seem to remember the terminal emulator on my old Psion 3 had the same property (you conventionally used Psion+C to copy and so on, so Ctrl+whatever was still available, and would send the appropriate character down the serial line).
Yes, there is a common clipboard mechanism. Once you understand that there are two separate clipboards (and that this is a feature), everything makes sense.
l - sp ec/clipboards.txt
Here's how it behaves in modern X environments like KDE 3, GNOME, XFCE, etc.:
- There is a clipboard (called CLIPBOARD in the specs), which you interact with by explicit copy and paste commands, for which the key bindings are conventionally Ctrl+C, Ctrl+V, Ctrl+X to copy, paste and cut respectively. Use it whenever you would use the Windows or Mac OS clipboard, teach it to new users, and so on.
- As an extra "easter egg", applications can manipulate the selection (the currently highlighted text) using the same API. The convention is to select text by dragging (or Shift+cursor keys, etc.) and to copy the selection from another program by pressing the middle mouse button. I will reassert: this is an "easter egg" for advanced users. The specs call this the "primary selection", PRIMARY (there is also a SECONDARY, but I am not aware of any program that uses it).
As documented here:
http://www.jwz.org/doc/x-cut-and-paste.htm
http://pdx.freedesktop.org/Standards/clipboards
OK, now the holes in that logical explanation:
- KDE 2 used to use Ctrl+C, Ctrl+V to manipulate PRIMARY. This was wrong and had all the flaws the poster cites. Solution: Upgrade to KDE 3, problem solved.
- Some other broken apps do the same. Solution: either fix them as you suggest, or stop using them. GNU Emacs 20 was apparently broken in the same way as KDE 2, while XEmacs and GNU Emacs 21 apparently work in the same way as KDE 3 (I can't confirm this, I use vim myself).
- Some (usually older) apps (like xterm) don't have copy or paste commands at all, but do have the selection/middle-click behaviour. Solution: either use something else (e.g. Konsole if you're a KDE fan) or learn the middle-click behaviour too. Since the command line is generally considered to be "hard", it shouldn't be that much of an intellectual leap.
- Ctrl+C already means something very common and specific (send a SIGINT) in console windows, so the standard Windows-style keybindings cannot be used in console windows. This is a historical clash between the Unix/DOS "Ctrl+C interrupts" and the Windows/OS2 "Ctrl+C copies" (on the Mac the convention is actually Command-C, so Ctrl is still available, and OS X's Terminal uses it as you'd expect) - Windows' MS-DOS-derived command prompt has the same conflict and a similar solution.
Version "numbers" aren't conventionally decimal numbers, at least in the Unix world; instead, you split the version up at the dots and compare succesive components, so 4.10 comes between 4.9 and 4.11, 4.100 is the version after 4.99, and so on. As a number, 4.10 would usually denote "four point one zero", but as a version number it's "four point ten" (or even "four dot ten", I suppose).
It looks less strange in a version numbering scheme with three or more components (Linux 2.4.26, Perl 5.8.1, Apache 1.3.20) where it's obvious that you're not dealing with decimal numbers. It's also consistent with the way sections are numbered in many textbooks, RFCs, W3C standards, etc. (chapter 1 section 2 would be headed "1.2", its subsection 20 would be headed "1.2.20".)
Most projects' second (minor) version number never reaches 10, since there's a new major release at least once every 10 minor releases (e.g. Apache 1.3 followed by 2.0, or Debian 2.2 followed by 3.0).
(A few projects do use decimal numbers: Perl used to, so the version before Perl 5.6.0 was something like Perl 5.00503, which would be Perl 5.5.3 in the new system.)
Meh, should have used preview. I of course meant to say that there are three problems on the Mac.
... no. Our three exploits are confused security boundaries, sloppy implementation, silly internal protocol handlers and an almost fanatical devotion to Steve Jobs... oh, I'll start again.)
(Nobody expects the MacOS Security Omission! Our two exploits are confused security boundaries, sloppy implementation and silly internal
Once my exams are over, I plan to look through the KDE ioslaves (at least the common ones in kdebase, kdenetwork etc.) and check what standards they comply with, and whether they appear to be exploitable. I'm not a security expert, but hey, many eyes, right?
.dmg is an expression of trust by the user, in which case Apple should never do it automatically (or at least have an unavoidable prompt before mounting remote .dmg files), or it's not, in which case newly mounted .dmg files should be considered to be untrusted and shouldn't be able to autorun anything. (Or both, of course.)
There are two problems on the Mac:
- Auto-registering protocols from all mounted images, while having URLs that mount a disk image with no user interaction.
Apple need to decide where to put the security barrier - either mounting a
- Some protocol handlers are mis-implemented, like the telnet one which accepts telnet:-nfoo (or telnet://-nfoo?) as a request to telnet to the host -nfoo, but naively invokes telnet with the argument -nfoo (which doesn't do what you want).
If Mac OS X telnet used GNU-style arguments, invoking telnet -- -nfoo would be sufficient to get the desired behaviour, but since it presumably doesn't, the telnet: protocol handler should be responsible for filtering out harmful hostnames.
(I observe that a non-GNUish telnet will be unable to connect to certain hosts via command-line arguments: if you actually have a host called -nfoo, it appears that at least Debian's Netkit telnet can only connect by running with no host parameter and instead using the command "open -nfoo")
- Silly internal protocol handlers which are hopelessly non-standard and may not have been designed with security in mind (help:, disk:, afp:, and so on). These "URLs" are also nowhere near as Universal as they claim to be.
KDE isn't any better in terms of number of nonstandard URI handlers, although I hope theirs are actually secure. On my computer, the Protocols page in KDE Info Centre lists the non-standard schemes about, ar, audiocd, bzip, bzip2, camera, cgi, devices, fish, floppy, fonts, ghelp, gzip, help, info, mac, man, metainfo, nfs, print, printdb, programs, psion, rdp, settings, system, tar, thumbnail, vnc, webcal, webdav/webdavs and zip; I'm not sure about the standards status of mms, mrml, rlogin, rtsp, sftp, sieve or smtp/smtps either.
At a quick glance, cgi: doesn't look like the most secure protocol imaginable, although it appears to only allow arbitrary program execution from folders nominated by the user (a list which defaults to being empty, at least on Debian), so it might actually be OK despite appearances.
It's a limitation of the Unix user model (and probably also the Windows user model) that only root can change userID to become a less priviledged user (programs like su, sudo, ksu, etc. are all setuid root, or at least communicate with something that is, in order to accomplish this). Making a program that can switch UID thus requires setuid bits and other unpleasantness, and requires active intervention from root.
/proc or /sys, which you'd normally want to do during boot).
:-)
(It's particularly nasty if you want to avoid active attacks rather than just mistakes, because you then have to ensure that you've irrevocably changed UID and that there's no going back - looking at Linux man pages, there are some unwelcome interactions between real, effective and saved UIDs, and between BSD and POSIX semantics.)
It would be nice to have some feature where there's a hierarchy of users, either hard-coded (e.g. a user fred can setuid() to any user whose name starts with fred-, but the sub-users can't setuid() back), or, better, dynamically defined by root (e.g. by writing something into
I might see if I can implement this after my exams finish: "Feudal Linux", perhaps?
Idle musing about what I'd want to happen, assuming that fred-www is a sub-user of fred:
- if a file's permissions let fred-www read or write it, so can fred
- if fred-www can traverse a directory, so can fred
- fred can't execute fred-www's files? Fairly useless in practice, since the problem is more likely to be with scripts, plugins etc., in which case it's the application's responsibility to protect users from accidentally executing other users' files
- fred can send signals to fred-www's processes (so kill/xkill still work, for when the browser crashes or uses excessive CPU time), but not vice versa (because otherwise fred-www could be extremely annoying)
- root (or, looking at kernel/sys.c, anyone with capability CAP_SETUID) implicitly has everyone else as a sub-user
Of course, this idea is partly inspired by the vapourware/semi-hoax project Jesux (I don't agree with the goal, but that doesn't mean they can't have good ideas
(Alternatively, User-mode Linux could be an idea to look into.)
That aside, further nitpicking:
I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix trick to prevent one from deleting their whole directory by accident.
If the attacker can't use command-line args, you're probably OK there:
If the attacker does "rm *" in your $HOME, yes, a file called "-i" could save you. None of these would be stopped, though: rm -rf
Another method is to have "alias rm rm -i" in your
Everything *you* run in an interactive csh or tcsh has that run first. If a malicious program is run through
If you don't want to be indexed, either use robots.txt, or the ROBOTS meta tag:
<meta name="ROBOTS" content="NOINDEX,NOFOLLOW"/>
In OS X, admin users have write access to /Applications even when not sudo'ed to root (to enable drag-and-drop installs), so it's possible to install many apps without using any priviledges. If the same user does "rm -rf /", those apps will disappear too.
If you want to kill your hidden config-files, try this:
/Users/foo and /Users (assuming your home directory is the OS X default /Users/foo). The second will not show you what you expect either.
..myfile; if you have such files, which you probably shouldn't, a pattern like ~/.[^.]* ~/..?* will notice them too.
rm -rf ~/.*
You can view these files like this:
ls -al ~/.*
The first will give you some error messages when it attempts to delete ~/. and ~/.., which are
The correct shell-glob pattern is probably ~/.[^.]* ([^.] means any character that isn't a dot). That will miss files called silly things like
To list hidden files, just doing "ls -a ~" or "ls -A ~" is simpler (I don't know whether -A works in OS X's BSD ls, but in GNU ls it's an alias for --almost-all, which shows everything except "." and ".."). As usual, add -l if you want the long-format listing.
IM2000 does sound like a good idea; it's basically the way I send inconveniently large attachments, in fact (zip, upload to temp directory on web server, send an email "covering note" with the URL, ask recipient to let me know when they've downloaded the file so I can delete it).
The immediate down side I can think of is that the sender knows (by observing their web server logs) that you received and read that message (or at least that you received it with a POP3-equivalent offline mail reader, which would presumably just have to download everything that wasn't blacklisted). This is possibly a good thing (debatable) if it's legit email, but is a bad thing if it's spam (the spammer now knows that joe@joe.com is a valid address which is read by a human).
Sorry, as far as I know, each model of Mac is only compatible with Airport *or* Airport Extreme (the expansion cards are different shapes or something stupid like that, I think) - titanium Powerbooks like mine can only use Airport non-Extreme (Hermes/Orinoco-based 11b chipset and well supported in Linux), the newer aluminium Powerbooks can only use Airport Extreme (based on Broadcom 11g chipset, no Linux drivers).
For recent Mac hardware in 2.4, you should apply a recent "benh" kernel patch to the appropriate version (in the current Debian unstable, kernel-patch-2.4.25-powerpc is the benh patch, and kernel-tree-2.4.25 provides the corresponding source; the precompiled PowerPC kernels are also compiled with this patch). Ben Herrenschmidt is one of the main Power Mac Linux developers.
Apparently Linus started using a Mac sometime during 2.5/2.6 development, so this patch is merged in 2.6.
I have a 12" G4 laptop DVI. I want linux, with suspend. Can't do that on the powerbook.
/sbin/snooze).
Actually, you probably can. Debian unstable works fine for me on a 15" Titanium Powerbook (the 1GHz one with DVI), and as I've commented above, suspend-to-RAM is fine (just install pmud and run it in the background; to sleep, close the lid or run
Unfortunately, the more recent Powerbooks have Airport Extreme, which isn't supported under Linux (because "Airport Extreme" cards are based on Broadcom chipsets, and Broadcom are extremely unhelpful), but if you're just running open-source and you can live with a slower 3D card than you mentioned (Radeon M9, which is the Mobility version of a Radeon 9000 I think), the same model Powerbook I have sounds ideal; you could try to find one second-hand.
The only component in my Powerbook that I know won't work with open-source drivers is the modem, and I can't say I've ever really wanted to use that anyway; I'm not sure about TV-out and DVI-out, but VGA-out certainly works, and I'm told the Firewire port should be OK too.
(The XFree86 Radeon driver is open-source and has at least some 3D acceleration, although I'm not sure whether it uses the card's full capabilities - it might not do full T&L or something. ATI has a more capable driver, but it's proprietary and they've only released it for x86.)
Bogomips *are* an objective measure, though. They're how many million times per second Linux can run a particular busy-loop, used for high precision timing (basically the same idea as how you did delays in old BASIC programs, i.e. FOR X%=1 TO 100000:NEXT X%, adjusting the large number down if you had a slow computer, or up if you had something blindingly fast like the 1.8MHz 6502 in a BBC Micro; ah, those were the days :-)
In other words, they're an objective measure of how fast your CPU can achieve absolutely nothing, hence the name bogomips (= millions of bogus instructions per second).
Old x86s generally do about a bogomip per MHz, newer ones (Pentium and up) do 2 bogomips per MHz due to different pipelines and such, so yes, they really *can* do twice as much nothing per clock cycle.
Of course, how fast a CPU can spin round and round a redundant loop has little relation to how much actual work it can do, so the only things bogomips are useful for are high-precision timing and pointless boasting.
(Different CPU architectures run different busy-loops in that part of the kernel, so in any case bogomips aren't directly comparable between architectures anyway. My G4 manages a little less than one PowerPC-bogomip per MHz.)
Personally I would say Linux is a good year from this level of sleep mode, but then I don't follow kernel dev too closely, so who knows.
/sbin/snooze (no special priviledges necessary) or just shut the lid. Both are handled by the Mac/PPC power management daemon, pmud.
Linux on x86, perhaps, but that's at least partly a hardware/APM/ACPI issue; PCs have historically had big problems with any sort of sleep mode, regardless of OS. Linux on Mac hardware, on the other hand, has much the same suspend-to-RAM behaviour as MacOS.
I've used Linux 2.4.2x and 2.6.5 on my Powerbook; both do pretty much what you said, but they're slower to sleep and wake up than MacOS (about 3 seconds to sleep and 1 second to wake up, while MacOS takes about half those times), and sometimes accidentally wake up when I plug in cables while they're asleep (USB mouse, power lead, network cable). Both of those differences are just trivial annoyances that waste a few seconds now and then, rather than anything serious.
To put the Powerbook in sleep mode you either run
I think you mean "format" or "wipe" or some such. fsck(8) is a Unix filesystem integrity checker (the Windows equivalent is Scandisk).
I glanced through the one for the DVI Powerbook G4 before the database ran out of filehandles and died; their photos for access to the underside of the Powerbook show the it with the keyboard/other components removed and the screen closed over the top, which I'm not convinced is a good idea (if something falls through the gap where the keyboard should go and onto the screen, it'll get scratched).
The Apple manual for the same model suggests putting the keyboard/wrist rest area of the laptop flat on a desk (with a towel or similar underneath), with the screen open and extended off the desk into your lap; that strikes me as less likely to get the screen damaged.