How about "chmod ug-s/bin/passwd"? Someone running passwd wouldn't be able to escallate their uid/gid. To change passwords, run su(do) first.
really now... what if your password expires and trying to change it with... err... passwd... gives you a nice error - access denied message? someone running passwd won't be able to do anything. Yeah, that takes care of eliminating the privilege escallation issue, but it kills the patient in the process.
the 's' bit is there for a reason - the user has to be able to modify its password hash in/etc/shadow which is only read/write by root! sudo is a moot point if all the users have do be allowed to do sudo/bin/passwd... and su, you'd have to be joking.
your solution only works if you can't patch the box and won't be adding any users, don't have password aging enabled and so on. Pretty narrow. Luckily, there is a patch from Sun:-)
And what he was saying is that this is no different than any root exploit in this respect, so it isn't a "bigger-than-average problem".
Actually, it kind of is. Remember that Solaris is considered by many the large, general-purpose multi-user Unix system(*). There aren't nearly as many multi-user Linux installs as there are Solaris instals. Government, military, education, you name it. Partially related to the all those certifications Sun has for it, partially to the (justified) mistrust in Windows for anything bigger than a medium-size multiuser server, partially due to the education system where the university ran solaris so future sysadmins learned that and then later used what they knew.
bottom-line: there are LOTS of Solaris machines out there and (too) many of them are large multiuser systems - meaning lots of untrusted users. As opposed to 'lots of Linux servers, not many of them with lots of untrusted users (yet). This will be a nightmare for many Solaris sysadmins.
(*) granted, given the Sparc's performance these days, that's one of the few left things one could still want to do with Solaris on big tin.
heah, like some tens of orders of magnitude for energy differences... heck, aren't we renormalizing that stuff already? talk about computing constant corrections to constants that one can't measure in the first place.
Not that it means it's all worthless. We get some pretty elegant tools for some pretty nontrivial stuff - math tools are physics-theory agnostic. But compelling? which one of them were you talking about? (point me please to the compelling theory of... quantum gravity for instance)
point: The energy uncertainty principle is connected to the vacuum fluctuations of all fields that interact with the field whose energy you're trying to measure.
hence: near the event horizon, the strongest fluctuating field is the gravitational field of the black hole - and you need quite a lot of energy for one of the 2 particles to escape, so the most probable source will be the hole's field. Fluctuations come as proprotional to the gradient of the field (through the field equations) so the larger the gradient (the smaller the hole) the more 'energetic' the virtual particles, thus the more energy the hole loses when one escapes. How's that for handwaving?
second - keyword virtual. The pair does not exist 'by itself' on shell. On the other hand, if one of the particles interacts with a real particle(/field) during its brief existence, it can acquire enough energy for the pair to appear 'on shell'. This is the other perspective from which you can argue that the hole loses mass - it has to generate the 'on-shell' particle that escapes.
(this is nowhere near a rigorous explanation, but since/. won't eat mathml anyway and ascii-art feynman diagrams are not an option...)
3. the jit should at some point just get out of the way of the program and just let it run. It's probably efficient enough that at some point the whole code be optimized and done with.
4. on the issue of cache misses and pipeline stalls, the jit is a beast. the less it gets to use the processor at all, the better.
5. JITs will suck on Itanium next to forever due to the weird optimization mechanisms of the platform. (well, 'forever' as in 'until Intel dropsthe whole itanic once and for all).
so you're saying the jvm can do just-in-time optimizations... ok, I'll grant you that. It CAN be a benefit. but let's take things with a grain of salt here.
(*)optimizations are expensive. compilers do multipass optimizations routinely. (*)jit optimizations have to come in parallel with the running code and this sucks resources in the beginnig.
So it boils down to something like a long-running java app might eventually end up as fast as, or faster, than a C/C++ counterpart. That is open to debate. The thing that is more certain is that you usually get better maintainability for java when changing platforms/instruction sets. This is tautological, as it comes from the very idea behind java.
The reason why I believe your argument is open to debate is that there are only so many optimizations the language will allow. It's not just a question of generating the machine code (although that comes in too - and it is expensive) Look at the long-standing issue of the language of choice for HPC - Fortran. C++ is so much better, but the compilers are not allowed to do optimizations as aggressively for c++ as for fortran. Hence, C++ code tends to be slower than Fortran code. Plus, there's always language overhead.
Bottom line is, there are always the 2 extreme cases and the 'in-between' ones. Java can be fast, provided you have the right combination of code (including coder) and jit compiler. But the same goes for native compilers as well, and in the real world this 'match made in heaven' rarely occurs.
The OS division would have happilly put in virus and firewall protection and you know why? BECAUSE THAT KIND OF STUFF BELONGS IN THE OS! (WoW).
assuming this (interesting??) idea didn't fall into the moronic category of 'all that runs on Windows belongs to the OS'...
there's an implicit circular reasoning here. windows is tightly integrated so for any 'service' to run decently enough it has to 'belong to the os' and all the stuff that gets added this way only increases integration. not a good idea. modular kernels (the long-forgotten starting point for NT) were about loose integration. so antivirus and firewall services are os add-ons.
on a different tune, since we all know Microsoft is singing the 'monthly update' song now, an integrated antivirus that will use windows update for signature updates will fare poorly - remember that most current antiviruses have a high-enough failure rate to bless us all with the recent epidemics. Microsoft will have to include a 'disable' feature to allow for competition in the field and guess how long will take the virus writers to update the list of scanners to disable at virus startup?
can you say 'false sense of security'?
Slashdot Mirror
No; you'll see a really bright magnet though - if you want to see the field, just get a spoonful of iron powder :-)
Then this release is early - they were supposed to wait until Debian finally moved to rpm!!!!
How about "chmod ug-s /bin/passwd"? Someone running passwd wouldn't be able to escallate their uid/gid. To change passwords, run su(do) first.
... what if your password expires and trying to change it with ... err ... passwd ... gives you a nice error - access denied message? someone running passwd won't be able to do anything. Yeah, that takes care of eliminating the privilege escallation issue, but it kills the patient in the process.
/etc/shadow which is only read/write by root! sudo is a moot point if all the users have do be allowed to do sudo /bin/passwd ... and su, you'd have to be joking.
:-)
really now
the 's' bit is there for a reason - the user has to be able to modify its password hash in
your solution only works if you can't patch the box and won't be adding any users, don't have password aging enabled and so on. Pretty narrow. Luckily, there is a patch from Sun
And what he was saying is that this is no different than any root exploit in this respect, so it isn't a "bigger-than-average problem".
Actually, it kind of is. Remember that Solaris is considered by many the large, general-purpose multi-user Unix system(*). There aren't nearly as many multi-user Linux installs as there are Solaris instals. Government, military, education, you name it. Partially related to the all those certifications Sun has for it, partially to the (justified) mistrust in Windows for anything bigger than a medium-size multiuser server, partially due to the education system where the university ran solaris so future sysadmins learned that and then later used what they knew.
bottom-line: there are LOTS of Solaris machines out there and (too) many of them are large multiuser systems - meaning lots of untrusted users. As opposed to 'lots of Linux servers, not many of them with lots of untrusted users (yet). This will be a nightmare for many Solaris sysadmins.
(*) granted, given the Sparc's performance these days, that's one of the few left things one could still want to do with Solaris on big tin.
heah, like some tens of orders of magnitude for energy differences ... heck, aren't we renormalizing that stuff already? talk about computing constant corrections to constants that one can't measure in the first place.
Not that it means it's all worthless. We get some pretty elegant tools for some pretty nontrivial stuff - math tools are physics-theory agnostic. But compelling? which one of them were you talking about? (point me please to the compelling theory of ... quantum gravity for instance)
point: The energy uncertainty principle is connected to the vacuum fluctuations of all fields that interact with the field whose energy you're trying to measure.
/. won't eat mathml anyway and ascii-art feynman diagrams are not an option ...)
hence: near the event horizon, the strongest fluctuating field is the gravitational field of the black hole - and you need quite a lot of energy for one of the 2 particles to escape, so the most probable source will be the hole's field. Fluctuations come as proprotional to the gradient of the field (through the field equations) so the larger the gradient (the smaller the hole) the more 'energetic' the virtual particles, thus the more energy the hole loses when one escapes. How's that for handwaving?
second - keyword virtual. The pair does not exist 'by itself' on shell. On the other hand, if one of the particles interacts with a real particle(/field) during its brief existence, it can acquire enough energy for the pair to appear 'on shell'. This is the other perspective from which you can argue that the hole loses mass - it has to generate the 'on-shell' particle that escapes.
(this is nowhere near a rigorous explanation, but since
3. the jit should at some point just get out of the way of the program and just let it run. It's probably efficient enough that at some point the whole code be optimized and done with.
4. on the issue of cache misses and pipeline stalls, the jit is a beast. the less it gets to use the processor at all, the better.
5. JITs will suck on Itanium next to forever due to the weird optimization mechanisms of the platform. (well, 'forever' as in 'until Intel dropsthe whole itanic once and for all).
so you're saying the jvm can do just-in-time optimizations ... ok, I'll grant you that. It CAN be a benefit. but let's take things with a grain of salt here.
(*)optimizations are expensive. compilers do multipass optimizations routinely.
(*)jit optimizations have to come in parallel with the running code and this sucks resources in the beginnig.
So it boils down to something like a long-running java app might eventually end up as fast as, or faster, than a C/C++ counterpart. That is open to debate. The thing that is more certain is that you usually get better maintainability for java when changing platforms/instruction sets. This is tautological, as it comes from the very idea behind java.
The reason why I believe your argument is open to debate is that there are only so many optimizations the language will allow. It's not just a question of generating the machine code (although that comes in too - and it is expensive) Look at the long-standing issue of the language of choice for HPC - Fortran. C++ is so much better, but the compilers are not allowed to do optimizations as aggressively for c++ as for fortran. Hence, C++ code tends to be slower than Fortran code. Plus, there's always language overhead.
Bottom line is, there are always the 2 extreme cases and the 'in-between' ones. Java can be fast, provided you have the right combination of code (including coder) and jit compiler. But the same goes for native compilers as well, and in the real world this 'match made in heaven' rarely occurs.
not only that - one will need to work a lot to just keep that bloat from giving one's (ever-fattening) servers a heart attack.
you're right, truly amazing analogy. I knew there was a reason I don't like McDonald's food.
The OS division would have happilly put in virus and firewall protection and you know why? BECAUSE THAT KIND OF STUFF BELONGS IN THE OS! (WoW). assuming this (interesting??) idea didn't fall into the moronic category of 'all that runs on Windows belongs to the OS' ...
there's an implicit circular reasoning here. windows is tightly integrated so for any 'service' to run decently enough it has to 'belong to the os' and all the stuff that gets added this way only increases integration. not a good idea. modular kernels (the long-forgotten starting point for NT) were about loose integration. so antivirus and firewall services are os add-ons.
on a different tune, since we all know Microsoft is singing the 'monthly update' song now, an integrated antivirus that will use windows update for signature updates will fare poorly - remember that most current antiviruses have a high-enough failure rate to bless us all with the recent epidemics. Microsoft will have to include a 'disable' feature to allow for competition in the field and guess how long will take the virus writers to update the list of scanners to disable at virus startup?
can you say 'false sense of security'?