Unfortunately, however, I dislike the idea that a newly deployed feature might be flagged as suspicious by an intermediary and disabled. This seems like it would create some very hard to diagnose problems - particularly if it rejects some statements from a transaction and not others. Now you may end up in an inconsistent state, and so your security tool might be what actually breaks you.
Just make sure you have the same system running in QA, and your QA people can log a defect against the developer from dirtcheapistan.
In certain environments it is useful having a tool like this, just so you have a contractual means of penalising the outsourced development house.
But does anyone here think Bill Gates or Microsoft stays awake worried about RH? They pulled in 72x more revenue, 159x more profits, and have 63x more cash on hand (50.69b vs 808m) than Red Hat. Microsoft even has a better profit margin than RH (32.5% vs 13.3%).
It doesn't forbid it, as I recall. It makes it optional and virtually every carrier opted not to as it gives them more control over the handsets.
Uh, no, not virtually every carrier, just the two US CDMA carriers. But, they are virtually the entire CDMA smartphone market, and since they don't want phone portability, the rest of the CDMA operators don't get it either.
And, this will be the death of CDMA (where I refer to cdma2000 and cdmaOne as CDMA).
I think present_arms's point is that local console access involves access to the big red switch
'Local access' typically means that you have means to start processes as non-root, but does not require that you are near the physical hardware. Physical access means you are near enough to access the 'big red switch'. Privilege escalation vulnerabilities typically allow you to get from 'local access' to 'local privileged access'. Combined with a remote vulnerability (which allows you to get from 'can't start and control processes' to 'can start and control processes') you can craft a remote root exploit.
and the bootloader, which on a PC-type system can be used to gain root by booting into single-user mode.
Assuming the administrator did not apply a bootloader password and BIOS passwords (to prevent booting from other media).
However, physical security is not sufficient to prevent 'local exploits', and methods that can be used where there is lack of physical security are a bit off-topic for this story..
"The announcement earlier this week that AT&T joined OpenStack, was greeted with much fanfare (of the 'woo hoo for open source' variety). But dig into why AT&T decided to sign up for OpenStack and things get a lot more interesting.
Would it be any better if AT&T used VMWare Cloud Director and other proprietary tools instead?
Why is it that a company that already provides physical server hosting (as most Telcos do) providing better virtual hosting (which most Telcos want to do) suddenly the creation of a walled garden?
No, it's not on the RHEL6 installation media, you have to have registered the box for RHN.
(RH is really pathetic this way, lots of useful packages are left off the installation media, seems they are forcing you towards satellite, but if you don't have the bandwidth for satellite, or need to setup a box without internet access, sorry for you if you want to something like use oscap - they give you openscap, but not openscap-utils). Oracle is better in this regard, with a public yum repo for release packages (not updates). Of course, CentOS gives you everything, as do all other community-oriented distros.
And the only 'innovation' over similar implementations (such as in Nokia Series 60, available since 2004), is the addition of the word 'touch screen' and 'gesture', in place of 'menu button' and 'click'.
N950 has keyboard, and as a "developer's device" permits you to disable Aegis completely
The *exact* method that worked on N950, reportedly worked (by design) on N9.
Aegis does have some value. I don't think N900 was ready for a mainstream audience, there would have been rootkit apps all over. Aegis goes some way to protecting users from malicious apps.
This month, I have a direct-from-Nokia N9, running Maemo 6/"MeeGo Harmattan" (not to be confused with mainstream MeeGo), with a nice security framework forbidding such dangerous actions as chroot to the user, and rendering huge chunks of system configuration non-modifiable. The promised "open mode", where you would own your own device, but not be able to access DRMed apps and media, never materialised,
Aegis is hindering my device usage in the name of protecting exactly fuck-all.
Just the same sort of crap as a typical Android phone, and just as open to abuse
Really? You mean preventing user apps from doing dangerous things without the user's knowledge is just as open to abuse as allowing everything?
Too many ambitious but clueless users on N900 have had to have their hands held through manually fixing or flashing their devices because they thought installing rootsh was cool. If it had been a mainstream device, I think there would have been a lot of exploits for it...
Since the N9 was intended (until Feb 12) to be a mainstream device, it really wouldn't have been a good idea to have gone with the totally open mode of N900.
Or, Kindle app (or any other e-book reader if you have epubs) on a smartphone which has TV out of some kind (A/V or mini HDMI or MHL), then the touch screen can be used to navigate pages.
My next phone will need to have full-disk encryption. I could do it on my N900 but it's a massive amount of work and I can't spare the processing power either.
How do you know the overhead of dm-crypt will actually have any noticeable impact on your N900's performance?
My N900 with CSSU has been performing quite well for the past month, but I'm not currently running kernel power.
One howto is here, but due to framebuffer not working in the titan kernel is not complete... and you need a non-stock kernel for dm-crypt (apparently, I wonder if it is possible to build just dm-crypt and dependencies for the stock kernel).
Have the voting-machine print your vote as the last step, then deposit this printed vote in a ballot-box the old-fashioned way.
They showed that it is possible to control the printer as well, so then it would depend on what is printed by the printer, and whether voters would notice.
And how much of that comes from vending/supporting "their" software (vs. selling hardware and taking cuts of everyone else's content and software that is sold via their "store")?
Firstly, this vulnerability has nothing to do with the LDAP server, or owning the LDAP server. It is effectively as if Mac OS X, when configured for LDAP authentication, has a 'auth sufficient pam_permit.so', so the client will accept any username or password. However, this doesn't imply any access to the LDAP server...
Once we own an LDAP server we own everything
Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it.
I have a few, where Kerberos is not really viable, and (since almost all access to anything is via ssh with public keys - but stored in LDAP), the passwords aren't really the issue, but the ssh public keys could be replaced...
I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file.
Why would it be any less awkward than Kerberos (besides the actual SSO part, but if you're not actually doing GSSAPI auth anywhere after login it is irrelevant)?
Maybe there exists a linux PAM module to change passwords etc inside LDAP, creating ldif files and running ldapmodify to change my password would get old real quick.
Almost all Linux distros have tools to configure a box for LDAP authentication, most of them get it right to set 'passwd' up so that it works correctly... even if you didn't have that, you could use 'ldappasswd' to change your password (but, it is probably a bit too inconvenient for most users).
However, if you have password policies configured (e.g. with slapo-ppolicy on OpenLDAP), and users log in to a display manager, they would be prompted to change their passwords on login (without having to touch the command line), just like you could do with Kerberos.
Re:Mandriva isn't trusted by the community
on
Mandriva 2011 Out
·
· Score: 5, Informative
Horse shit. I use Mandriva on a number of critical systems, and I know many others who do the same.
[...]
I've already downloaded the new Mandriva, will put it on my test system later tonight, and will most likely upgrade a dozen or more servers over the week.
Long-time Mandrake, Mandriva and now Mageia contributor here... I would warn you that in the past, a lot of server-related packages were maintained by the community (apache and php being about the only ones maintained by one over-worked employee). For a number of reasons, a lot of those contributors have become disenfranchised with Mandriva, and have been porting their work over to Mageia. Thus far, my packages are still in sync between the two, but recent events have been motivating me to rather consolidate my work on Mageia:
New Mandriva employees making significant (bad) changes to packages which are officially maintained by a community contributor, without consultation.
Lack of communication with contributor community, with sudden changes to the release plan (one month prior to the planned release, and after the original RC date - which is usually when version freeze kicks in - the release was moved out by 2.5 months). This makes it quite difficult for contributors to plan their contributions (e.g. I put some effort into getting my packages up-to-date for the May freeze date - during times when I had lots of other responsibilities - only to have my effort effectively wasted).
Lack of commitment to support of development infrastructure - there appears to be little internal support for the development infrastructure, contributors have been doing a lot of the work of maintaining the build cluster, and when they aren't available, it is often off-line for days at a time. In addition, there has been conflict with some of these contributors, so they are now resentful of being the only support for the build cluster.
Animosity by the RPM5 protagonists
Lack of effort in supporting the traditional (non-Live-rsync-all-files-to-disk) installer, which is critical in any server-focused environment. Apparently it still works, but if there are bugs they probably won't be addressed.
These issues seem to not be affecting Mageia much, so now that 2011 is out, and I will be forced to decide between Mandriva and Mageia for my own uses, I will probably be upgrading all my Mandriva 2010.1 machines to Magiea, and will probably move all my effort to Mageia and orphan my Mandriva packages (like many other contributors have done). The current focus of Mandriva is not sufficient for my own uses, so I believe my contributions will be of more value to myself in Mageia than Mandriva.
Note to all users considering Mandriva 2011, note that while an upgrade to Mandriva 2011 should be relatively painless, a later crossgrade to Mageia will not be (due to the RPM5 switch in Mandriva 2011), while a cross-grade from Mandriva 2010.1 to Mageia should also be as painless as upgrading to Mandriva 2011. So, while I won't tell you to ditch Mandriva, you should pause at this stage to decide if you are currently on Mandriva 2010.x.
At its current pace, Nokia was on track to introduce only three MeeGo-driven models before 2014
And Nokia's problem so far has been having too few models? And they're biggest competitor launches how many phones a year?
It is evident from a number of sources that are or were inside Nokia that Meego/Harmattan was delayed due to continual direction changes by management. I believe Meego/Harmattan, if it had been shipped by February 2011, even with 1 device a year, would have been sufficient to make Nokia's Qt strategy successful.
But, too many devices leads to a lack of hardware accessories from 3rd parties, too many form factors for developers to consider (right, Qt/QML would make it easy for most apps), too much divergence in software between devices, leading to fewer updates, leading to shorter support lifetimes, leading to resentment from customers, leading to smaller market share.
I think Nokia still hasn't managed to figure out what it is that they are doing wrong. It certainly wasn't their Qt strategy, or Linux-based devices, or tablets...
The V490, V890, E6900, E20000, E25000 stopped shipping in April 2009. The V445 is Ultrasparc IIIi, was announced in 2007, I think first shipped in 2008, with Solaris 10. So it won't even make *one* OS upgrade?
Strange, most place I dealt with the server was gone when the support ran out, which was typically 3 to 5 years depending on the contract.
So, you didn't have any "big iron" then?
Now since i'm sure Oracle doesn't sell support for this hardware anymore
They do.
I bet most companies have already shitcanned them or sold them off, so I bet this will only affect a minority at best. For those that are still running what is frankly in computing terms ancient hardware it isn't like there aren't free Linux distros that will run on these machines,
You want to run an unsupported, experimental port of Linux on an E6900, or an E10000, or an E20000?
and if you are so concerned about money you are running actual business on a server that old frankly I doubt you're gonna pay for an upgrade to the latest and greatest Solaris anyway.
In this market (midrange servers), it's usually not about the money, but the supposed "stability". And, you wouldn't pay to upgrade, you've been paying premium software support to be able to run whatever version of Solaris is supported.
So I don't see this as any different than say MSFT saying they wouldn't support running Winserver 2K10 on a P4, since that is the age we are talking about here. I just don't see old servers getting expensive new OSes, that just wouldn't make any sense. Maybe someone can chime in here and say why they'd buy new server licenses to run on 6 year old tech?
Our company bought new UltraSparc III and IV servers (V215s, V445s) in 2008 (bad decision, I didn't support it). At the same time we bought Sun X4450 Intel-based servers. Guess which ones will still have a supported OS in 7 year's time? The cheaper ones with 4 times the cores.
We ARE talking servers from 2005-2007 here. Servers unlikely and unsuitable for production or any other professional use anyway.
In some environments, the only reason SPARC boxes were bought was for their longer support lifetime (e.g. "minimum of 7 years support") than competing x86 models.
Since virtualising old installs is more difficult on Solaris for SPARC, I predict this will just accelerate migrations to x86, or for environments that need midrange servers, PPC or Itanium.
... as most users don't use vanilla upstream kernels. And, most distributors / distros have a supported release which provides Xen Dom0 support (including Red Hat).
Slashdot Mirror
Unfortunately, however, I dislike the idea that a newly deployed feature might be flagged as suspicious by an intermediary and disabled. This seems like it would create some very hard to diagnose problems - particularly if it rejects some statements from a transaction and not others. Now you may end up in an inconsistent state, and so your security tool might be what actually breaks you.
Just make sure you have the same system running in QA, and your QA people can log a defect against the developer from dirtcheapistan.
In certain environments it is useful having a tool like this, just so you have a contractual means of penalising the outsourced development house.
But does anyone here think Bill Gates or Microsoft stays awake worried about RH? They pulled in 72x more revenue, 159x more profits, and have 63x more cash on hand (50.69b vs 808m) than Red Hat. Microsoft even has a better profit margin than RH (32.5% vs 13.3%).
http://finance.yahoo.com/q/ks?s=msft
http://finance.yahoo.com/q/ks?s=RHT+Key+Statistics
But, if RH takes all of MSs market share in areas they compete in, RH will still have lower revenues/profit in that area than MS.
Because the customer is saving.
Revenue comparison is irrelevant here, revenue loss (including potential) by MS and market share are more relevant.
By their actions (adopting open source, when 5 years ago they were attacking it) shows they are worried enough to try and fight it now.
It doesn't forbid it, as I recall. It makes it optional and virtually every carrier opted not to as it gives them more control over the handsets.
Uh, no, not virtually every carrier, just the two US CDMA carriers. But, they are virtually the entire CDMA smartphone market, and since they don't want phone portability, the rest of the CDMA operators don't get it either.
And, this will be the death of CDMA (where I refer to cdma2000 and cdmaOne as CDMA).
I think present_arms's point is that local console access involves access to the big red switch
'Local access' typically means that you have means to start processes as non-root, but does not require that you are near the physical hardware. Physical access means you are near enough to access the 'big red switch'. Privilege escalation vulnerabilities typically allow you to get from 'local access' to 'local privileged access'. Combined with a remote vulnerability (which allows you to get from 'can't start and control processes' to 'can start and control processes') you can craft a remote root exploit.
and the bootloader, which on a PC-type system can be used to gain root by booting into single-user mode.
Assuming the administrator did not apply a bootloader password and BIOS passwords (to prevent booting from other media).
However, physical security is not sufficient to prevent 'local exploits', and methods that can be used where there is lack of physical security are a bit off-topic for this story..
Would it be any better if AT&T used VMWare Cloud Director and other proprietary tools instead?
Why is it that a company that already provides physical server hosting (as most Telcos do) providing better virtual hosting (which most Telcos want to do) suddenly the creation of a walled garden?
It (libpcap-devel-1.0.0-6.20091201git117cb5.el6.x86_64.rpm) is there, in the RHEL Server Optional channel.
yum install libpcap-devel
No, it's not on the RHEL6 installation media, you have to have registered the box for RHN.
(RH is really pathetic this way, lots of useful packages are left off the installation media, seems they are forcing you towards satellite, but if you don't have the bandwidth for satellite, or need to setup a box without internet access, sorry for you if you want to something like use oscap - they give you openscap, but not openscap-utils). Oracle is better in this regard, with a public yum repo for release packages (not updates). Of course, CentOS gives you everything, as do all other community-oriented distros.
And the only 'innovation' over similar implementations (such as in Nokia Series 60, available since 2004), is the addition of the word 'touch screen' and 'gesture', in place of 'menu button' and 'click'.
N950 has keyboard, and as a "developer's device" permits you to disable Aegis completely
The *exact* method that worked on N950, reportedly worked (by design) on N9.
Aegis does have some value. I don't think N900 was ready for a mainstream audience, there would have been rootkit apps all over. Aegis goes some way to protecting users from malicious apps.
\
This month, I have a direct-from-Nokia N9, running Maemo 6/"MeeGo Harmattan" (not to be confused with mainstream MeeGo), with a nice security framework forbidding such dangerous actions as chroot to the user, and rendering huge chunks of system configuration non-modifiable. The promised "open mode", where you would own your own device, but not be able to access DRMed apps and media, never materialised,
The open mode is implemented, and apparently as of the beta2 for N950 the intended mechanism works. Users with N9's on PR1.0 are reporting that they can boot a minimally patched kernel into open mode.
Aegis is hindering my device usage in the name of protecting exactly fuck-all.
Just the same sort of crap as a typical Android phone, and just as open to abuse
Really? You mean preventing user apps from doing dangerous things without the user's knowledge is just as open to abuse as allowing everything?
Too many ambitious but clueless users on N900 have had to have their hands held through manually fixing or flashing their devices because they thought installing rootsh was cool. If it had been a mainstream device, I think there would have been a lot of exploits for it ...
Since the N9 was intended (until Feb 12) to be a mainstream device, it really wouldn't have been a good idea to have gone with the totally open mode of N900.
Or, Kindle app (or any other e-book reader if you have epubs) on a smartphone which has TV out of some kind (A/V or mini HDMI or MHL), then the touch screen can be used to navigate pages.
Maybe first Facebook can support displaying existing comment fields and meta-data on photos like some other photo hosting sites.
Have you tried recent kernel-power releases?
My next phone will need to have full-disk encryption. I could do it on my N900 but it's a massive amount of work and I can't spare the processing power either.
How do you know the overhead of dm-crypt will actually have any noticeable impact on your N900's performance?
My N900 with CSSU has been performing quite well for the past month, but I'm not currently running kernel power.
One howto is here, but due to framebuffer not working in the titan kernel is not complete ... and you need a non-stock kernel for dm-crypt (apparently, I wonder if it is possible to build just dm-crypt and dependencies for the stock kernel).
Have the voting-machine print your vote as the last step, then deposit this printed vote in a ballot-box the old-fashioned way.
They showed that it is possible to control the printer as well, so then it would depend on what is printed by the printer, and whether voters would notice.
And how much of that comes from vending/supporting "their" software (vs. selling hardware and taking cuts of everyone else's content and software that is sold via their "store")?
No. This is a vulnerability in the client-side portion, as if you had configured a linux client with:
auth sufficient pam_permit.so
It should have no effect on any other clients.
Firstly, this vulnerability has nothing to do with the LDAP server, or owning the LDAP server. It is effectively as if Mac OS X, when configured for LDAP authentication, has a 'auth sufficient pam_permit.so', so the client will accept any username or password. However, this doesn't imply any access to the LDAP server ...
Once we own an LDAP server we own everything
Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it.
I have a few, where Kerberos is not really viable, and (since almost all access to anything is via ssh with public keys - but stored in LDAP), the passwords aren't really the issue, but the ssh public keys could be replaced ...
I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file.
Why would it be any less awkward than Kerberos (besides the actual SSO part, but if you're not actually doing GSSAPI auth anywhere after login it is irrelevant)?
Maybe there exists a linux PAM module to change passwords etc inside LDAP, creating ldif files and running ldapmodify to change my password would get old real quick.
Almost all Linux distros have tools to configure a box for LDAP authentication, most of them get it right to set 'passwd' up so that it works correctly ... even if you didn't have that, you could use 'ldappasswd' to change your password (but, it is probably a bit too inconvenient for most users).
However, if you have password policies configured (e.g. with slapo-ppolicy on OpenLDAP), and users log in to a display manager, they would be prompted to change their passwords on login (without having to touch the command line), just like you could do with Kerberos.
Horse shit. I use Mandriva on a number of critical systems, and I know many others who do the same.
[...]
I've already downloaded the new Mandriva, will put it on my test system later tonight, and will most likely upgrade a dozen or more servers over the week.
Long-time Mandrake, Mandriva and now Mageia contributor here ... I would warn you that in the past, a lot of server-related packages were maintained by the community (apache and php being about the only ones maintained by one over-worked employee). For a number of reasons, a lot of those contributors have become disenfranchised with Mandriva, and have been porting their work over to Mageia. Thus far, my packages are still in sync between the two, but recent events have been motivating me to rather consolidate my work on Mageia:
These issues seem to not be affecting Mageia much, so now that 2011 is out, and I will be forced to decide between Mandriva and Mageia for my own uses, I will probably be upgrading all my Mandriva 2010.1 machines to Magiea, and will probably move all my effort to Mageia and orphan my Mandriva packages (like many other contributors have done). The current focus of Mandriva is not sufficient for my own uses, so I believe my contributions will be of more value to myself in Mageia than Mandriva.
Note to all users considering Mandriva 2011, note that while an upgrade to Mandriva 2011 should be relatively painless, a later crossgrade to Mageia will not be (due to the RPM5 switch in Mandriva 2011), while a cross-grade from Mandriva 2010.1 to Mageia should also be as painless as upgrading to Mandriva 2011. So, while I won't tell you to ditch Mandriva, you should pause at this stage to decide if you are currently on Mandriva 2010.x.
This story is about LibreOffice, not OpenOffice.org. In LibreOffice (3.3.2) on Windows 7 x64, I don't have this problem ...
Now MeeGo is ready
That's hardly what this article says.
At its current pace, Nokia was on track to introduce only three MeeGo-driven models before 2014
And Nokia's problem so far has been having too few models? And they're biggest competitor launches how many phones a year?
It is evident from a number of sources that are or were inside Nokia that Meego/Harmattan was delayed due to continual direction changes by management. I believe Meego/Harmattan, if it had been shipped by February 2011, even with 1 device a year, would have been sufficient to make Nokia's Qt strategy successful.
But, too many devices leads to a lack of hardware accessories from 3rd parties, too many form factors for developers to consider (right, Qt/QML would make it easy for most apps), too much divergence in software between devices, leading to fewer updates, leading to shorter support lifetimes, leading to resentment from customers, leading to smaller market share.
I think Nokia still hasn't managed to figure out what it is that they are doing wrong. It certainly wasn't their Qt strategy, or Linux-based devices, or tablets ...
We ARE talking servers from 2005-2007 here.
The V490, V890, E6900, E20000, E25000 stopped shipping in April 2009. The V445 is Ultrasparc IIIi, was announced in 2007, I think first shipped in 2008, with Solaris 10. So it won't even make *one* OS upgrade?
Strange, most place I dealt with the server was gone when the support ran out, which was typically 3 to 5 years depending on the contract.
So, you didn't have any "big iron" then?
Now since i'm sure Oracle doesn't sell support for this hardware anymore
They do.
I bet most companies have already shitcanned them or sold them off, so I bet this will only affect a minority at best. For those that are still running what is frankly in computing terms ancient hardware it isn't like there aren't free Linux distros that will run on these machines,
You want to run an unsupported, experimental port of Linux on an E6900, or an E10000, or an E20000?
and if you are so concerned about money you are running actual business on a server that old frankly I doubt you're gonna pay for an upgrade to the latest and greatest Solaris anyway.
In this market (midrange servers), it's usually not about the money, but the supposed "stability". And, you wouldn't pay to upgrade, you've been paying premium software support to be able to run whatever version of Solaris is supported.
So I don't see this as any different than say MSFT saying they wouldn't support running Winserver 2K10 on a P4, since that is the age we are talking about here. I just don't see old servers getting expensive new OSes, that just wouldn't make any sense. Maybe someone can chime in here and say why they'd buy new server licenses to run on 6 year old tech?
Our company bought new UltraSparc III and IV servers (V215s, V445s) in 2008 (bad decision, I didn't support it). At the same time we bought Sun X4450 Intel-based servers. Guess which ones will still have a supported OS in 7 year's time? The cheaper ones with 4 times the cores.
We ARE talking servers from 2005-2007 here. Servers unlikely and unsuitable for production or any other professional use anyway.
In some environments, the only reason SPARC boxes were bought was for their longer support lifetime (e.g. "minimum of 7 years support") than competing x86 models.
Since virtualising old installs is more difficult on Solaris for SPARC, I predict this will just accelerate migrations to x86, or for environments that need midrange servers, PPC or Itanium.
... as most users don't use vanilla upstream kernels. And, most distributors / distros have a supported release which provides Xen Dom0 support (including Red Hat).