Am Fr den 6. Nov 2015 um 19:18 schrieb Serge E. Hallyn:It's still unavoidable in a number of cases. It's easy to re-write scripts to fit any local configuration. It's not anywhere near as easy to re-write a compiled program to account for any local configuration.
A piece of system configuration software needs to do some
networking setup with some privilege, including calling scripts. It can
either do so as root or not at all - polluting every program that will end
up getting called with fI is not only ugly but simply doesn't work (because
scripts). Saying that the whole thing must be written as self-contained
executable that never needs to be re-execed is frequently unrealistic.
So this allows a piece of software to run with reduce privilege, and it
is an improvement over the previous state of affairs.
Having some scripts in the process is definitively a nightmare to
control. That should be prevented wherever possible. And usually it is
as the scripts might be used for computing some values that are used
later in privileged stuff.
This is debatable. While the app should be giving a user friendly error message, getting a stack-trace and the exception name (and the exceptions are usually sanely named) is still far better than just getting something like 'Segmentation Fault', or just returning the error in the return code. There is no added security from not providing the stack-trace because there is no data leaked by it (it contains no information about the contents of variables, and function names and included libraries can easily be seen by just looking at the python program itself).
However, that usecase has one more flaw I think. It is the human nature.
Someone that create a tool made for running as root or especially SUID
is usually careful to do so. If they know right now that the tool is
never run as root, then they don't care about many thinks that needs to
get addressed for root stuff.
Good example are all that userspace python tools that throw all that
stack traces around the users ears (I don't know if that saying exists
in English...) instead of giving proper error messages.
If you're getting duplicates with the same Message-ID header, then your mail-server is (arguably) broken. It should be delivering exactly one copy of a message with a given Message-ID: header (this is really a de-facto standard, GMail, Yahoo, and most other mail-providers do this, as does Exchange. Postfix does not, but it's pretty easy to work around with some filtering and procmail).
I would have been happy if there had been a default-off PR_ENABLE_AMBIENT
prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but
the current set of rules which removes bits from pA whenever doing an
action which capability-aware software does something which it would have
reasonably expected to drop privilege is a nice safeguard.
Well, not really. You can only prevent ambient capabilities to be given
to tools you don't want to have any capabilities by setting that tool
SUID or setting just one random capability for it.
By the way, guys, can we start to _not_ add every one in this discussion
to the Cc? Currently I get every mail twice. One from the list and one
from Cc. I still leave all Ccs intact with this mail but I would prefer
to just reply to the list. If anybody is not reading the list and would
like to get the mail, please insist.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature