Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:regular expression optimiser (Score 1) 190

thanks thegarbz - i didn't mention that i added in pyzor and razor, and i think clamav as well. also as my domain's been up for a while it does receive a considerable amount of spam. the load just got to be too much. i'll investigate alternatives and also bear in mind that spamassassin worked well for you.

Comment regular expression optimiser (Score 2) 190

i'd be interested to see what happens if you run those regex's through this:
        http://bisqwit.iki.fi/source/regexopt.html

btw can we please get a copy of the patterns you're using? i think they might prove useful for other people. also i'd like to test them myself against regexopt.

oh - to the other person who suggested spamassassin? i tried that, i set it up to run at MTA-time. it often took THIRTY SECONDS to process a message. in fact it was so bad that i was forced to set a limit of 100k on incoming messages, as a lot of virus-ridden word documents (etc) were typically over 100k. that cut down the amount of CPU cycles but it was still far far too much memory and far too CPU intensive.

the one thing that did work well is greylisting, however the problem with greylisting i find is that if you happen not to be at the computer or have direct access to the server and people on the phone say "i'm sending you a message now, have you got it?" you *know* it's going to be at least an hour before it'll arrive. so, unless you can whitelist them in advance (which you can't always do) greylisting does actually interfere with legitimate business.

anyway: in the end i gave up and went to gmail, but with gmail fucking up how they're doing things i have to revisit this and set up a mail server again. thus we come full circle...

Comment Re:Wait...what? (Score 2) 208

which means the genes will actively spread in wild plants due to natural selection.

and we've seen how the introduction of rabbits, foxes and other non-naturally-occurring animals into australia worked out, and how japanese bind weed has worked out when introduced outside of japan.

i cannot begin to voice how insanely dangerous it is to put random genes into food crops like this. the nightmare i "made up" one day was these insane "time-bomb" crops, where crops can be planted and grow but the seeds it creates are sterile. "commercially" this is incredibly "valuable" as it allows total control over the supply. now imagine some completely insane person creating "generation" time-bomb seeds, which grow, seed, grow, seed then grow sterile. now imagine _those_ cross-pollenating with wild crops and other species. you'd be looking at a world-wide famine in 5-10 years as the time-bomb gene would be both latent and undetectable.

what really shocked me was that i heard *ten years ago* that time-bomb crops ALREADY EXIST.

Comment Re:SE/Linux (and SE/Android) (Score 1) 240

But root is still the key capability in configuring the environment.

And Linux distros always have a way for root to disable boot-time or run-time SE Linux.

in SE/Linux, root is "parallel-tracked". in SE/Linux it's just yet another username. in fact, there is no such concept as usernames under FLASK. uids are just a convenient piece of information to place into the "security context" but so is the filename, directory name, port number, protocol (UDP, TCP), ip address - all these things are *also* part of the security context. more recently they've extended SE/Linux so that X11 primitives can also be added to the security context.

i forget the exact details - it's been a while

Comment Re:SE/Linux (and SE/Android) (Score 1) 240

the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.

Indeed, but in the case of SE Linux the Five Star General ( root ) is also the guy who writes the rules about where he is allowed to go and what he is allowed do ( SE Linux config ).

ah *no*! he most definitely is not! again, you may be under the mistaken impression that the 5 star general has more power than he appears. if he were to start ordering people to bypass security measures, that would seriously be a breach of standard security protocol and his subordinates would report him.

but you may have misunderstood: if a 5 star general walks out of a secure area without his passport, how is he going to get on a commercial flight? he doesn't have a passport, because he didn't return his badge at the gate. mr 5 star general doesn't have control over commercial flights, does he? without identification papers, he doesn't even have control over *military* flights, let alone commercial ones.

in other words, you've misunderstood the analogy, because you are under the mistaken assumption that even a 5 star general actually has any "power" or "authority" outside of his domain and responsibilities: he doesn't. it's *all* about context, *not* about the "person". in other words it doesn't matter if he's a 5 star general, if he steps outside of the bounds of responsibility within the context that he's SPECIFICALLY been tasked to do, in that physical location, at that specific time, and under the specific circumstances, then all hell breaks loose and security alarms go off like mad.

is that clearer?

taking this away from the analogy, the OEM would prepare the OS, set the SE/Linux files up, digitally-sign the bootloader, flash it into ROM, digitally-sign the kernel, require the bootloader to check it.... then give *you* the root password, knowing full well that because SE/Linux is permanently enabled it is flat-out impossible for you - even though you have root access (a 5 star general) - to even replace the kernel, because the SE/Linux permissions explicitly forbid overwriting of the boot partition. and even though you have root, the SE/Linux permissions forbid you from chmodding the boot subdirectory.

SE Linux doesn't make root go away, it just usefully reduces the need for root day-to-day. But root is still the key capability in configuring the environment.

And Linux distros always have a way for root to disable boot-time or run-time SE Linux.

not in treacherous DRM-locked systems they don't - the ones where the bootloader is in a digitally-signed ROM which you cannot modify, where the kernel and its boot parameters are also digitally-signed and cannot be modified.

Comment EXPLICITLY ask them NOT to send the private key (Score 2) 399

this is really important. people who don't know what ssh keys are will typically send you the id_rsa (private) key file.

IT IS VERY IMPORTANT that you say to them EXPLICITLY and VERY CLEARLY, "please send me the public key file *only*. DO NOT send me the PRIVATE key. you can identify the private key because it is named xyz. i ONLY want you to send me the PUBLIC key, it is named xyz.pub. if you send me the private key, you will have to destroy it and we will have to start again, so ONLY send me the PUBLIC key, ok?"

and get them to acknowledge what you've said. do not be afraid to "piss them off" by having to be so absolutely specific. make sure you end the sentence with what you *want* them to do, *not* what you *don't* want them to do. depending on the person they could potentially remove the "negative" by their subconscious and do exactly what you ask... with the words "no", "not", "don't" etc. removed.

also if you want to be paranoid then use the signature-thing (fingerprint). get them to read it out to you over the phone (not by email).

Comment SE/Linux (and SE/Android) (Score 5, Interesting) 240

there's an extremely common mistake made which needs to be pointed out: the clue is in the phrase "This kind of top-down thinking". the fundamental assumption is that there is a concept of "more privilege is required than before" to achieve privileged tasks. people imagine that security is hierarchical - that the further towards "the top" you get, the more access you are permitted. this is simply NOT TRUE. the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.

so, people invent new security systems, but they invent them without actual proper thought towards design, and they invent them thinking that this "top down" hierarchical approach is the only way. thus, new APIs have to be invented.

there is another way: it's called SE/Linux (and there's a variant called SE/Android). SE/Linux follows the FLASK model, which basically says that based on the current context, the current application, that a new executable is given a COMPLETELY new security context, where the new privileges have to be explicitly given. the most important implication of this model is: it absolutely does not matter how "powerful" you were in the previous context - the one that fires up the new executable; the new one is literally a completely and utterly separate security context.

to give an example: take a 5 Star General, and send him to a security base. when he gets there, standard security procedure: they take away his passport and all his credentials, and they give him a security pass (a new context). that security pass has a pre-prepared set of restricted corridors and rooms that the 5 Star General can go to. he can go to the conference room, and the bathroom. if he tries to leave without returning the security pass, he has no passport, and no papers.

this incredibly powerful security model - FLASK basically fits on top of an OS *without* interfering with it. it's particularly fascinating because it can watch which programs exec() other programs, and it can watch what APIs those programs use.... *without* needing to actually modify those programs.

basically what i'm saying is that the problem that cyanogen is trying to solve already has a way in which it can be solved, if the SE/Android team haven't already solved it. and that's because, under SE/Linux and SE/Android, you can operate both the normal "root access" system *in parallel* with SE/Linux. all you need to do is create a FLASK security context which restricts access to only those applications that *should* be accessing the restricted APIs. you don't need to modify the applications, nor do anything special to the underlying OS.

Comment Re:Looks interesting (Score 2) 33

Well, the big philosophical idea is that ANY EOMA-68 CPU card slots in ANY EOMA-68 machine (note that EOMA is not entirely, or even primarily about tablets -- that's just the first hardware product using it), and works. That's why Luke (aka lkcl) is quite adamant there are no "optional" features in the spec -- the only exception is for interfaces (e.g. USB, 10/100/1000-BASE-T) that can fully autonegotiate in both directions, so that there's neither a slow-machine/fast-cpu-card, nor slow-cpu-card/fast-machine case where it becomes incompatible.

yup. that's about the long and short of it. although it's at first consideration a complete pain for system designers on both sides of the interface - a nuisance for CPU Card designers because they have to substitute extra ICs such as USB-to-SATA in cases where they pick a SoC that doesn't have SATA - and bewilderment for I/O Board designers because why would they use a CPU Card in e.g. a tablet that has features they don't need such as Ethernet?? - the alternatives are absolute chaos.

the advantage: you can tell the average end-user "just buy one of these, it will work".

the alternative: think about this scenario as it is in many other standards such as Q-Seven , where you allow ethernet to be "optional" and you allow the I/O boards to "recreate" ethernet say using USB-to-Ethernet. how do you route that? well, if you think about it what you have to do is actually put down an Ethernet Hub IC on *every single I/O board*, and some sort of crazed switching, as well as put down a USB-to-Ethernet converter IC and probably a USB Hub IC as well... because the designers of the I/O board will never know if an end-user is going to plug in a CPU Card that has native Ethernet or is expecting it to be left up to the I/O Board using USB.

now expand that chaos out to SATA as well, as well as any other interfaces, and you can see immediately that a non-optional standard results in instant chaos. it's fine for Q-Seven (well... it's not. not really) where the expectation is that the Q-Seven Cards will never be removed from their carrier boards, but then why build a standard where the end-user is never expected to upgrade their system without needing a specialist degree in engineering in order to assess if the upgrade will even work?

the guiding principles behind the EOMA standards are: it must be SIMPLE, it must be OPEN, and it must work in HUGE volume.

Comment what the heck? (Score 1) 94

why didn't they post stories on slashdot?? then they would have got some attention. in fact... hang on: why have i *never* seen an article on h-online cross-referenced anywhere, and why have i *never* seen them in a google search??

Slashdot Top Deals

Imagination is more important than knowledge. -- Albert Einstein

Working...