"It is FAR more likely that they would target PC's outside of the US, to avoid possible legal action."
which immediately makes the host countries "complicit" with the efforts of the united states, thus making them legitimate targets as well.
which, in the case of a wartime situation, would arguably make them justifiably _real_ targets as well.
overall this is a monumentally fucking stupid idea of the united states air force, at every single level, in every single possible way, without exception and without any doubt.
accidental downloading of large bits of "spam" will contain encrypted data which, when the CPU notices that the network interfaces (or the nearby electro-magnetic spectrum) are blipping up-and-down in some not-exactly-random pattern, begins to interpret the SPAM (or EM noise) in some morse-code-like way that activates the CPU to "phone home".
suddenly all the DRM in your hard drive and motherboard which is normally used for DMCA coercion, gets activated for other purposes.
given that the encryption in the DRM is at a level higher than the highest level specified by the DoD for ultra-top-secret material, it will of course be perfect for taking over your computer.
overall i wish i was entirely joking about this, but it unfortunately makes far too cohesive a story.
when you go into a real-world office, where is the filing cabinet? do you find that the filing cabinet is on the floor, or on top of the desk? (the "desk top")
where is the "calendar"? is it a) on the wall b) on the top of the desk?
where is the "flip-chart"? is it a) on a 3-legged easel on the floor b) on the wall c) on the "top of the desk"?
where is the "wall clock"? is it a) on the wall b) on the ceiling c) on the "top of the desk"?
where is the "wall paper"? is it a) on the wall b) on the floor c) on the "top of the desk"?
this should clearly illustrate to you that the "desktop metaphor" - look up the book "beyond the desktop metaphor" - is clearly broken.
and it is only people who are "used to" the "desktop" metaphor who find that anything _other_ than the "top of the desk" metaphor to be difficult to cope with.
personally, i find SUGAR to be seethingly annoying - and that's because i, personally, run fvwm, xterms, and when i want to run another program i type the command "firefox" or "skype" into one of the xterms. and so anything that doesn't have an easy way to navigate a 3x3 set of "desk tops" i find exceedingly frustrating, or if it's excessively pretty, i find it excessively slow.
hence, i have been thinking for quite some time about taking compiz-fusion or 3ddesktop, merging something like bzflag or other 3D game or virtual reality into a REAL "office" metaphor.
on the "desk", which will have four legs and a chair in front of it, will be several "monitors". on each "monitor" there will be a "desk top" showing one application per monitor. on the other side of the "room" there will be a Television, which, when you want to play DVDs you will "click" on the "remote control" with your mouse and it will change channels.
the WinAmp and xmms "skin" will quite literally be on the front of a 3D remote-control.
there will be a bakerlite telephone on the "desk", which, if you click on it, you get taken to skype, kiax and other applications which run "communications".
there will be a "filing cabinet" which, when you click on a "drawer", up pops a series of REAL folders, with little tabs on them displaying A-D E-H.... V-Z which you can "click" on, and the folder will "pop up" and show you a series of icons of the files in that "folder" !
there will be a "book case" containing actual books, and CDs, and your DVD library. clicking on a DVD will make it "fly through the air" towards the TV. clicking on a "book" will open the web site. or fire up the PDF viewer. or take you to google's site. or fire up gopher _whatever_.
_this_ is the kind of paradigm that is entirely missing from computing - one based on "reality".
oh - and if you're wondering if this is entirely impossible and science fiction, i recently ran the beryl desktop on a 600mhz ULV Pentium M processor, which had only a 512k cache, and it had an older style intel extreme graphics chipset - 855 or maybe even 815.
i was running the ondemand cpufreqd module.
at 1280 x 1024, this 600mhz CPU didn't even make it above 450mhz.
yes, pretty much that's it - but, truly, don't say i didn't warn you about it being horrendous!
basically, "roles" and "contexts" can "track" different stages in your application, across different boundaries. the triggers between boundaries are typically things like "exec()" is the most obvious one, but you can explicitly tell selinux - via a system call with a c interface - to "change context right now, please".
typically this function call is made in a PAM module, and in this way, when someone authenticates, the application gets to change "context" - and of course because it's done in PAM there's no code changes required to your application.
but there are many more system calls on which "context changes" can be made, thus subdividing your application up even further.
the above scenario i described - where ssh shell access is only permitted from one set of ip addresses by one set of users, and sftp is allowed from a different set of ip addresses by a different set of users - is the extreeeeeme case.
the "default" setup that selinux has is of course to "allow all incoming port 80 and 443 for any user on any interface" for httpd, etc. etc.
use of "open source" needs to be stopped - period - for two reasons:
1) this example license falls into the category of "open source":
"here's some source code. you can look at it. therefore it's 'open'. isn't it pretty. if you use it or anything you learn from it, we'll sue you for everything you've got. please indicate your acceptance."
"open source" licenses do not convey the right to make any use of the code. encouraging companies to get away with this by "opening" the source code is clearly not ok, and i would advocate that anyone faced with such a license simply not do business with such a company: the code should be "free software" or you walk away. this sends a clear message.
2) "open source" in military intelligence communities has a very very specific meaning: it means "a source that is open". i.e. "a source - of information - that is uncontrolled". i.e. a source - e.g. a leak - which is beyond the control of an intelligence agency to stop further information from leaking out of it.
so an "open source" is a nightmare for intelligence communities that has to be shut down at all costs.
therefore, to use the phrase "open source" in a military environment when referring to "source code of computer programs" has nasty connotations associated with it that rings massive alarm bells.
in all, the sooner that people stop using the phrase "open source" and correct people - repeatedly - to use the phrase "free software" the better.
"they often don't understand how insanely powerful it is...."
mwahahahah. yeah. nor how much money can be made from being able to program it and set up selinux policies that make normal people's brains bleed:) from scratch, selinux takes about 6 to 8 weeks to understand and program "policies". that means that anyone with the skill to program it is onto a goldmine, especially in the kinds of defense and civil contracts where selinux is "required".
i did a contract for a veeery unusual selinux deployment, involving file transfers from a high security environment to a low security one and vice-versa (secure-ftp). the requirement was that files in "incoming" should be creatable-and-writeable from one side, and from the other side they should be "readable-and-deletable" on the other.
the requirement was nothing to do with UNIX, it was implementing guidelines laid out in a policy document on security and was government-mandated for the type of environment (i wasn't told what that was but it was probably banking).
when my friend analysed the requirements, he did a simple map of POSIX permissions onto the requirements. POSIX merges "write" with "delete". automatically and immediately, pure POSIX permissions made it absolutely impossible to fulfil the requirements. he looked at extended ACLs: that didn't help, either.
on investigation of SElinux permissions, with extended separate permissions on directories as well as files, it was abundantly clear that SElinux fitted the requirements perfectly.
in SElinux, every single OS primitive has its own ACL permission, so there are about twenty five ACLs for files and a further separate and distinct twenty five or so ACLs for subdirectories. thirty or more for sockets. network addresses can be represented in ACLs. it's just... absolutely insanely powerful, just as you say.
you could, if you were prepared to drive yourself up the wall, implement a per-user firewall for ssh. not using ssh configs but using selinux policy files! you could define the set of IP addresses which become relevant for a particular user context, which gets activated when the user logs in because PAM helps define the user's role, and then the combination of the user's role and the fact that the ssh "context" is entered, then network access is granted or denied because...... i'm belabouring the point but you get the picture i'm sure. oh. and of course, you could even define that a particular ssh subsystem (sftp) be allowed from a particular range of IP addresses and ssh "shell" access only allowed from another range.
the "NSA" is not developing "your" OS. the NSA is (indirectly) verifying via (indirect) sponsorship and advocation that an (independent) university-developed scientific security model (FLASK) is (independently) implemented by a company and then (independently) maintained by (independent) people such as stephen smalley.
look at the web site. it say "POSIX not good enough for proper security. therefore we make it better so that civil services, and other environments where security matters, have someone to go to to ask 'is this secure to level XYZ?' and get a certification"
the bottom line is: be damn grateful for their involvement because it beefs up linux and allows it to be recommended for deployment in places where it would otherwise be hopelessly outclassed. remember: selinux allows linux to be "certified" as "secure", and mathematically provable as "secure". those certifications are absolutely vital for deployment in certain kinds of environments.
so be glad that linux is getting a leg-up, thanks to the NSA.
if you believe that selinux is "an utter pain in the ass" then you have misunderstood what selinux is for. selinux is specifically designed to be able to PROVE that an application is secure, using formal mathematical analysis (of the policy files).
[ the principle on which selinux works is that when you change "security context", it doesn't matter a damn if you were "god" before, you're now starting from scratch with zero permissions in the new context unless otherwise specified. this is best illustrated with an example of when you go into a military environment, they take your ID badge away from you and issue you with a temporary one that is only relevant inside that building. you can't even leave the building without that temporary badge, and it's been coded to only let you go to the toilet and into the rooms that are associated with your specific purpose for being in that building. and of course, if you forget to get your permanent ID back once you _do_ leave, you'll find it very difficult to get out the country! ]
one of the "rules" that GCHQ and the NSA follow is that it is perfectly acceptable for something to be "insecure" as long as you KNOW that it's insecure: you can then provide a workaround or a fix to ensure that the security vulnerability is never exploited.
the one thing that you absolutely absolutely must not ever have is a situation where you don't KNOW whether something is "secure" or "insecure".
so if AppArmour has wonderful automated rulesets that are impossible to analyse...
the thing about selinux is that policies require that you understand the source code and what the application is doing. for example, one of the guidelines is that applications should use exec rather than fork, because that provides total privilege separation, obviously, between tasks. fork() does not provide such a complete level of privilege separation, and so up until quite recently there was absolutely no way in selinux to even step into a separate security context on a fork() - it just... wasn't... even... remotely worth considering.
however, it turns out that there were some specific instances why stepping into a different security context on fork() is actually useful (such as in samba) and so it was added in. due to the circumstances under which this could be thoroughly abused, it was decided that it should be provided only via an explict selinux function call (usually, you can just provide an selinux policy statement without any code modifications).
there are two definitions of "trusted computing", and it depends on who is doing the trusting.
the first definition basically boils down to "we don't trust users" - and is the version of trusted computing that you're describing.
the second definition basically says "we want users to be able to trust their computers and be able to do what they want without worrying".
it should be fairly obvious which definition that a linux-based, free-software-backed distribution will go for, especially with the backing and quiet involvement of a couple of heads of police departments, and several professors from royal holloway.
Re:ANSI SQL conformance?
on
Pro MySQL
·
· Score: 1
it's ansi 200N sql. postgresql doesn't support it yet, on the basis that if it doesn't even have a year, they ain't gonna add it:)
don't use mysql for professional projects!
on
Pro MySQL
·
· Score: 4, Insightful
specifically, don't use it for 'comprehensive' projects, involving many programming teams and/or a hundred tables. don't even consider using MySQL 5 for at least another four years, for such projects, until it matures - and by that time, PostgreSQL, an already mature product that has had Views, Triggers etc. right from the start, will have had even more rigorous testing.
Stargate is in the same league as 'The Matrix' and 'Dr Who', and is better than Firefly for scope.
Stargate combines technology and mysticism in an 'everyday' and transparently 'acceptable' manner ('believable' is not an appropriate word to use because it requires that you 'check in' - "do i believe this? mmm... yep! oh drat - missed an important plotline there...)
the storyline - and the background - are breathtaking in scope: on a par with Ian Bank's 'Culture' series but more dynamic, gripping and immediate than Ian Bank's 'Culture' series (which is more violent, thoughtful, and explorative of technology and aliens and the origins of both).
we get to see 'real' people making 'real' decisions - a lot of them fire-fighting - so it's realistic: humans screw up, they get duped, they get dumped on. only by the skin of their teeth, through ingenuity, and by not giving up do they pull through.
now - you could say that a lot of sci-fi series have the same characteristics: 'Star Trek' was the first really pioneering series which brought the same level of commitment from its characters; others followed, but even 'Star Trek' became old very quickly (even with 78 or so episodes).
In all, there really isn't (hasn't been) any other series which has all the characteristics that make a sci-fi series truly fantastic and a real engaging pleasure to watch and to look forward to. My guess is that the SCI FI channel will be absolutely kicking themselves once it sinks in what they have lost, because the Stargate shows are _so_ good at what they do that I believe that the SCI FI channel has become complacent (familiarity breeds contempt...) and simply takes it for granted.
as if we haven't got enough to fucking worry about with global warming, now the american military has to go fuck with the ionosphere as well. i mean jesus fucking christ what _exactly_ do they want to try to do: accelerate the death of everybody?? have they actually studied what the ionosphere actually _does_?
hey you stupid american military dicks: get your dicks out of your collective arses and STOP fucking with the planet, for god's sake.
did it _ever_ occur to you _why_ those radio waves are bounced back by the ionosphere??
FUCK your satellites - we have ENOUGH to worry about without your stupid arrogance killing us off.
there's a better way: Terminal Server capability
on
ReactOS 0.3 RC1 Released
·
· Score: 5, Interesting
there's an even better way to make ReactOS incredibly useful: add in terminal server capability. then once you have a server running in the [virtual-]machine of your choice, you can then run rdesktop or other thin client to connect to it.
here's the thing: the original developers of NT 3.1 were _not_ going to add a GUI: they planned it as a DOS-like (actually VMS-like) "thing" - and were told "from on high" to get it "windowsey". what make ReactOS so interesting is that such a goal could ultimately be achieved - making it much easier to virtualise because you wouldn't need a full desktop environment in the virtual machine: just a command prompt.
the difficulty with putting ReactOS into a virtual machine like XEN - which is a hybrid VM architecture - is that you need to rewrite your HAL (hardware abstraction layer) to fit on top of XEN, not to fit on top of "real" hardware.
here's the real kicker about that: once you _have_ written a XEN-HAL for ReactOS - with complete source code available to you - there exists a strong possibility of being able to "drop in" those.SYS and.DLL components _directly_ into Windows NT 5.0 (aka Windows 2000, Windows 2003 and Windows XP) and actually have it work.
here's the thing: the fact that you have the source code means that you can consider adding the FLASK security model to it, thereby providing a proper MAC control over what programs can and cannot do.
note: i didn't say that this would be a _small_ project - i just said that it would be _possible_.
and here's the kicker: the DLLs and.SYS drivers and.EXEs produced for ReactOS are near-drop-in-replacements for their windows equivalents.
there therefore exists a strong possibility of being able to run Windows NT 5.0 (aka windows 2000 and windows 2003 and windows XP) in a "secure" mode - by replacing key components with ReactOS components.
microsoft couldn't be xxxxing bothered to put decent security into their OS (they don't make money from doing that) so someone else has to consider doing it for them.
it's still possible to program properly in PHP - by ignoring the inlining aspect, and doing the programming in "pure" php and then doing templating manually, using for example HTMLTMPL.
aspects of zope also blow goats. dtml and ZPT/TAL are just as shit as PHP - and just as shit as mod_python's PSP.
why? because ALL of these things allow "inlining" of code - intermingling of code and HTML.
and that's just piss-poor programming and a complete nightmare to understand.
the trouble is that because you CAN do it, people WILL do it.
web pages should be static or they should be templated. anything else is asking for trouble.
so give me some friggin money, i'll go get a bath, cut me hair, buy a suit, shoes, get a life _and_ still write better code than the dicks who take thousands or millions of dollars to tell you jack shit!
Slashdot Mirror
http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/
"Somehow I don't see all the manufactures and consumers getting on board with this"
... _asked the manufacturer's permission_ ????
you mean... you think they
"Security researchers simply trying to help people keep their systems secure could wind up running afoul of the US military."
only if those security researchers work for U.S. companies.
"It is FAR more likely that they would target PC's outside of the US, to avoid possible legal action."
which immediately makes the host countries "complicit" with the efforts of the united states, thus making them legitimate targets as well.
which, in the case of a wartime situation, would arguably make them justifiably _real_ targets as well.
overall this is a monumentally fucking stupid idea of the united states air force, at every single level, in every single possible way, without exception and without any doubt.
not at all - it will go into the CPUs.
accidental downloading of large bits of "spam" will contain encrypted data which, when the CPU notices that the network interfaces (or the nearby electro-magnetic spectrum) are blipping up-and-down in some not-exactly-random pattern, begins to interpret the SPAM (or EM noise) in some morse-code-like way that activates the CPU to "phone home".
suddenly all the DRM in your hard drive and motherboard which is normally used for DMCA coercion, gets activated for other purposes.
given that the encryption in the DRM is at a level higher than the highest level specified by the DoD for ultra-top-secret material, it will of course be perfect for taking over your computer.
overall i wish i was entirely joking about this, but it unfortunately makes far too cohesive a story.
let's call it a joke, anyway. ha ha.
"Why reinvent a very good wheel?"
.... V-Z which you can "click" on, and the folder will "pop up" and show you a series of icons of the files in that "folder" !
actually, it's an incredibly bad paradigm.
when you go into a real-world office, where is the filing cabinet? do you find that the filing cabinet is on the floor, or on top of the desk? (the "desk top")
where is the "calendar"? is it a) on the wall b) on the top of the desk?
where is the "flip-chart"? is it a) on a 3-legged easel on the floor b) on the wall c) on the "top of the desk"?
where is the "wall clock"? is it a) on the wall b) on the ceiling c) on the "top of the desk"?
where is the "wall paper"? is it a) on the wall b) on the floor c) on the "top of the desk"?
this should clearly illustrate to you that the "desktop metaphor" - look up the book "beyond the desktop metaphor" - is clearly broken.
and it is only people who are "used to" the "desktop" metaphor who find that anything _other_ than the "top of the desk" metaphor to be difficult to cope with.
personally, i find SUGAR to be seethingly annoying - and that's because i, personally, run fvwm, xterms, and when i want to run another program i type the command "firefox" or "skype" into one of the xterms. and so anything that doesn't have an easy way to navigate a 3x3 set of "desk tops" i find exceedingly frustrating, or if it's excessively pretty, i find it excessively slow.
hence, i have been thinking for quite some time about taking compiz-fusion or 3ddesktop, merging something like bzflag or other 3D game or virtual reality into a REAL "office" metaphor.
on the "desk", which will have four legs and a chair in front of it, will be several "monitors". on each "monitor" there will be a "desk top" showing one application per monitor. on the other side of the "room" there will be a Television, which, when you want to play DVDs you will "click" on the "remote control" with your mouse and it will change channels.
the WinAmp and xmms "skin" will quite literally be on the front of a 3D remote-control.
there will be a bakerlite telephone on the "desk", which, if you click on it, you get taken to skype, kiax and other applications which run "communications".
there will be a "filing cabinet" which, when you click on a "drawer", up pops a series of REAL folders, with little tabs on them displaying A-D E-H
there will be a "book case" containing actual books, and CDs, and your DVD library. clicking on a DVD will make it "fly through the air" towards the TV. clicking on a "book" will open the web site. or fire up the PDF viewer. or take you to google's site. or fire up gopher _whatever_.
_this_ is the kind of paradigm that is entirely missing from computing - one based on "reality".
oh - and if you're wondering if this is entirely impossible and science fiction, i recently ran the beryl desktop on a 600mhz ULV Pentium M processor, which had only a 512k cache, and it had an older style intel extreme graphics chipset - 855 or maybe even 815.
i was running the ondemand cpufreqd module.
at 1280 x 1024, this 600mhz CPU didn't even make it above 450mhz.
yes - i clarified later with a correction that you of course must do fork() followed by exec() to create an (isolated) child process.
sorry!
yes, pretty much that's it - but, truly, don't say i didn't warn you about it being horrendous!
basically, "roles" and "contexts" can "track" different stages in your application, across different boundaries. the triggers between boundaries are typically things like "exec()" is the most obvious one, but you can explicitly tell selinux - via a system call with a c interface - to "change context right now, please".
typically this function call is made in a PAM module, and in this way, when someone authenticates, the application gets to change "context" - and of course because it's done in PAM there's no code changes required to your application.
but there are many more system calls on which "context changes" can be made, thus subdividing your application up even further.
the above scenario i described - where ssh shell access is only permitted from one set of ip addresses by one set of users, and sftp is allowed from a different set of ip addresses by a different set of users - is the extreeeeeme case.
the "default" setup that selinux has is of course to "allow all incoming port 80 and 443 for any user on any interface" for httpd, etc. etc.
http://www.armedforcesjournal.com/forums/showthread.php?t=3375884
the entire article is full of some amazingly badly thought out justifications and ideas.
there are a stack of alternative solutions which protect computers or evade attack entirely, with diminishing returns on each of course.
use of "open source" needs to be stopped - period - for two reasons:
1) this example license falls into the category of "open source":
"here's some source code. you can look at it. therefore it's 'open'. isn't it pretty. if you use it or anything you learn from it, we'll sue you for everything you've got. please indicate your acceptance."
"open source" licenses do not convey the right to make any use of the code. encouraging companies to get away with this by "opening" the source code is clearly not ok, and i would advocate that anyone faced with such a license simply not do business with such a company: the code should be "free software" or you walk away. this sends a clear message.
2) "open source" in military intelligence communities has a very very specific meaning: it means "a source that is open". i.e. "a source - of information - that is uncontrolled". i.e. a source - e.g. a leak - which is beyond the control of an intelligence agency to stop further information from leaking out of it.
so an "open source" is a nightmare for intelligence communities that has to be shut down at all costs.
therefore, to use the phrase "open source" in a military environment when referring to "source code of computer programs" has nasty connotations associated with it that rings massive alarm bells.
in all, the sooner that people stop using the phrase "open source" and correct people - repeatedly - to use the phrase "free software" the better.
yes i think i do :) [mean fork() followed by exec()].
as opposed to just fork() which then shares some resources and continues to use them - e.g. file handles etc.
"they often don't understand how insanely powerful it is...."
:) from scratch, selinux takes about 6 to 8 weeks to understand and program "policies". that means that anyone with the skill to program it is onto a goldmine, especially in the kinds of defense and civil contracts where selinux is "required".
... absolutely insanely powerful, just as you say.
... i'm belabouring the point but you get the picture i'm sure. oh. and of course, you could even define that a particular ssh subsystem (sftp) be allowed from a particular range of IP addresses and ssh "shell" access only allowed from another range.
mwahahahah. yeah. nor how much money can be made from being able to program it and set up selinux policies that make normal people's brains bleed
i did a contract for a veeery unusual selinux deployment, involving file transfers from a high security environment to a low security one and vice-versa (secure-ftp). the requirement was that files in "incoming" should be creatable-and-writeable from one side, and from the other side they should be "readable-and-deletable" on the other.
the requirement was nothing to do with UNIX, it was implementing guidelines laid out in a policy document on security and was government-mandated for the type of environment (i wasn't told what that was but it was probably banking).
when my friend analysed the requirements, he did a simple map of POSIX permissions onto the requirements. POSIX merges "write" with "delete". automatically and immediately, pure POSIX permissions made it absolutely impossible to fulfil the requirements. he looked at extended ACLs: that didn't help, either.
on investigation of SElinux permissions, with extended separate permissions on directories as well as files, it was abundantly clear that SElinux fitted the requirements perfectly.
in SElinux, every single OS primitive has its own ACL permission, so there are about twenty five ACLs for files and a further separate and distinct twenty five or so ACLs for subdirectories. thirty or more for sockets. network addresses can be represented in ACLs. it's just
you could, if you were prepared to drive yourself up the wall, implement a per-user firewall for ssh. not using ssh configs but using selinux policy files! you could define the set of IP addresses which become relevant for a particular user context, which gets activated when the user logs in because PAM helps define the user's role, and then the combination of the user's role and the fact that the ssh "context" is entered, then network access is granted or denied because...
it is truly truly absolutely amazing.
the "NSA" is not developing "your" OS. the NSA is (indirectly) verifying via (indirect) sponsorship and advocation that an (independent) university-developed scientific security model (FLASK) is (independently) implemented by a company and then (independently) maintained by (independent) people such as stephen smalley.
look at the web site. it say "POSIX not good enough for proper security. therefore we make it better so that civil services, and other environments where security matters, have someone to go to to ask 'is this secure to level XYZ?' and get a certification"
the bottom line is: be damn grateful for their involvement because it beefs up linux and allows it to be recommended for deployment in places where it would otherwise be hopelessly outclassed. remember: selinux allows linux to be "certified" as "secure", and mathematically provable as "secure". those certifications are absolutely vital for deployment in certain kinds of environments.
so be glad that linux is getting a leg-up, thanks to the NSA.
if you believe that selinux is "an utter pain in the ass" then you have misunderstood what selinux is for. selinux is specifically designed to be able to PROVE that an application is secure, using formal mathematical analysis (of the policy files).
... even ... remotely worth considering.
[ the principle on which selinux works is that when you change "security context", it doesn't matter a damn if you were "god" before, you're now starting from scratch with zero permissions in the new context unless otherwise specified. this is best illustrated with an example of when you go into a military environment, they take your ID badge away from you and issue you with a temporary one that is only relevant inside that building. you can't even leave the building without that temporary badge, and it's been coded to only let you go to the toilet and into the rooms that are associated with your specific purpose for being in that building. and of course, if you forget to get your permanent ID back once you _do_ leave, you'll find it very difficult to get out the country! ]
one of the "rules" that GCHQ and the NSA follow is that it is perfectly acceptable for something to be "insecure" as long as you KNOW that it's insecure: you can then provide a workaround or a fix to ensure that the security vulnerability is never exploited.
the one thing that you absolutely absolutely must not ever have is a situation where you don't KNOW whether something is "secure" or "insecure".
so if AppArmour has wonderful automated rulesets that are impossible to analyse...
the thing about selinux is that policies require that you understand the source code and what the application is doing. for example, one of the guidelines is that applications should use exec rather than fork, because that provides total privilege separation, obviously, between tasks. fork() does not provide such a complete level of privilege separation, and so up until quite recently there was absolutely no way in selinux to even step into a separate security context on a fork() - it just... wasn't
however, it turns out that there were some specific instances why stepping into a different security context on fork() is actually useful (such as in samba) and so it was added in. due to the circumstances under which this could be thoroughly abused, it was decided that it should be provided only via an explict selinux function call (usually, you can just provide an selinux policy statement without any code modifications).
there are two definitions of "trusted computing", and it depends on who is doing the trusting.
the first definition basically boils down to "we don't trust users" - and is the version of trusted computing that you're describing.
the second definition basically says "we want users to be able to trust their computers and be able to do what they want without worrying".
it should be fairly obvious which definition that a linux-based, free-software-backed distribution will go for, especially with the backing and quiet involvement of a couple of heads of police departments, and several professors from royal holloway.
it's ansi 200N sql. :)
postgresql doesn't support it yet, on the basis that if it doesn't
even have a year, they ain't gonna add it
specifically, don't use it for 'comprehensive' projects, involving many programming teams and/or a hundred tables.
don't even consider using MySQL 5 for at least another four years, for such projects, until it matures - and by that time, PostgreSQL, an already mature product that has had Views, Triggers etc. right from the start, will have had even more rigorous testing.
see http://advogato.org/article/894.html for details.
Stargate is in the same league as 'The Matrix' and 'Dr Who', and is better than Firefly for scope.
Stargate combines technology and mysticism in an 'everyday' and transparently 'acceptable' manner
('believable' is not an appropriate word to use because it requires that you 'check in' - "do i believe this?
mmm... yep! oh drat - missed an important plotline there...)
the storyline - and the background - are breathtaking in scope: on a par with Ian Bank's 'Culture' series
but more dynamic, gripping and immediate than Ian Bank's 'Culture' series (which is more violent, thoughtful,
and explorative of technology and aliens and the origins of both).
we get to see 'real' people making 'real' decisions - a lot of them fire-fighting - so it's realistic:
humans screw up, they get duped, they get dumped on. only by the skin of their teeth, through ingenuity,
and by not giving up do they pull through.
now - you could say that a lot of sci-fi series have the same characteristics: 'Star Trek' was the first
really pioneering series which brought the same level of commitment from its characters; others followed,
but even 'Star Trek' became old very quickly (even with 78 or so episodes).
In all, there really isn't (hasn't been) any other series which has all the characteristics that make a sci-fi
series truly fantastic and a real engaging pleasure to watch and to look forward to. My guess is that
the SCI FI channel will be absolutely kicking themselves once it sinks in what they have lost, because the
Stargate shows are _so_ good at what they do that I believe that the SCI FI channel has become complacent
(familiarity breeds contempt...) and simply takes it for granted.
as if we haven't got enough to fucking worry about with global warming, now the american military has to go fuck with the ionosphere as well. i mean jesus fucking christ what _exactly_ do they want to try to do: accelerate the death of everybody?? have they actually studied what the ionosphere actually _does_?
hey you stupid american military dicks: get your dicks out of your collective arses and STOP fucking with the planet, for god's sake.
did it _ever_ occur to you _why_ those radio waves are bounced back by the ionosphere??
FUCK your satellites - we have ENOUGH to worry about without your stupid arrogance killing us off.
there's an even better way to make ReactOS incredibly useful: add in terminal server capability.
.SYS and .DLL components _directly_ into Windows NT 5.0 (aka Windows 2000, Windows 2003 and Windows XP) and actually have it work.
then once you have a server running in the [virtual-]machine of your choice, you can then run rdesktop or other thin client to connect to it.
here's the thing: the original developers of NT 3.1 were _not_ going to add a GUI: they planned it as a DOS-like (actually VMS-like) "thing" - and were told "from on high" to get it "windowsey". what make ReactOS so interesting is that such a goal could ultimately be achieved - making it much easier to virtualise because you wouldn't need a full desktop environment in the virtual machine: just a command prompt.
the difficulty with putting ReactOS into a virtual machine like XEN - which is a hybrid VM architecture - is that you need to rewrite your HAL (hardware abstraction layer) to fit on top of XEN, not to fit on top of "real" hardware.
here's the real kicker about that: once you _have_ written a XEN-HAL for ReactOS - with complete source code available to you - there exists a strong possibility of being able to "drop in" those
here's the thing: the fact that you have the source code means that you can consider adding the FLASK security model to it, thereby providing a proper MAC control over what programs can and cannot do.
.SYS drivers and .EXEs produced for ReactOS are near-drop-in-replacements for their windows equivalents.
note: i didn't say that this would be a _small_ project - i just said that it would be _possible_.
and here's the kicker: the DLLs and
there therefore exists a strong possibility of being able to run Windows NT 5.0 (aka windows 2000 and windows 2003 and windows XP) in a "secure" mode - by replacing key components with ReactOS components.
microsoft couldn't be xxxxing bothered to put decent security into their OS (they don't make money from doing that) so someone else has to consider doing it for them.
neat, huh?
wrong attitude. absolutely the wrong attitude.
it's still possible to program properly in PHP - by ignoring the inlining aspect,
and doing the programming in "pure" php and then doing templating manually, using
for example HTMLTMPL.
aspects of zope also blow goats. dtml and ZPT/TAL are just as shit as PHP - and
just as shit as mod_python's PSP.
why? because ALL of these things allow "inlining" of code - intermingling of
code and HTML.
and that's just piss-poor programming and a complete nightmare to understand.
the trouble is that because you CAN do it, people WILL do it.
web pages should be static or they should be templated. anything else is asking
for trouble.
more on this at http://advogato.org/article/882.html.
so give me some friggin money, i'll go get a bath,
cut me hair, buy a suit, shoes, get a life _and_
still write better code than the dicks who take
thousands or millions of dollars to tell you jack shit!
tsk tsk, mr DHS examiner.
don't you know that giving out grades to kids doesn't make
them ready for the reeealll world....
he he - like kids at school, passing exams doesn't make you ready for life :)