On Fri, Apr 13, 2012 at 10:26:06AM -0400, Daniel J Walsh wrote:
Trying to fix all apps that could include confidential data from Programmer
Debugging tools which are a very small percentage of users use, is just crazy.
It isn't just debugging tools that would break, also things like wine, the
On Thu, Apr 12, 2012 at 04:01:58PM -0400, Daniel J Walsh wrote:
On 04/12/2012 02:39 PM, Mark Wielaard wrote:
On Mon, Apr 09, 2012 at 09:38:40AM -0400, Eric Paris wrote:
(Think about it a moment. gdb -p is the same as firefox trying to ptrace
gnome-keyring)
I thought a bit about it.
On 04/13/2012 03:55 AM, Mark Wielaard wrote:
On Thu, Apr 12, 2012 at 04:01:58PM -0400, Daniel J Walsh wrote:
On 04/12/2012 02:39 PM, Mark Wielaard wrote:
On Mon, Apr 09, 2012 at 09:38:40AM -0400, Eric Paris wrote:
(Think about it a moment. gdb -p is the same as firefox trying to
ptrace
On Wed, 2012-04-11 at 10:51 -0400, Daniel J Walsh wrote:
On 04/11/2012 10:21 AM, Matthew Garrett wrote:
I'm in favour of keeping ptrace available for F17 - I don't think we've had
enough opportunity to discuss the tradeoffs.
deny_ptrace will be DISABLED for F17. Already checked in.
dwalsh wrote:
[...] deny_ptrace will be DISABLED for F17. Already checked in. [...]
Note that the selinux-policy rpm update that corrects this has not yet
been pushed to any yum update/-testing channels. It would be a shame
if the f17 beta spin went out with this bug.
On Thu, Apr 12, 2012 at 4:53 PM, Frank Ch. Eigler f...@redhat.com wrote:
dwalsh wrote:
[...] deny_ptrace will be DISABLED for F17. Already checked in. [...]
Note that the selinux-policy rpm update that corrects this has not yet
been pushed to any yum update/-testing channels. It would be
Niels de Vos said:
On Mon, Apr 9, 2012 at 3:38 PM, Eric Paris eparis at redhat.com wrote:
On Mon, 2012-04-09 at 00:31 +0200, Kevin Kofler wrote:
It also
breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by
disabling the flag in kde-runtime's %post script, but there are
On Thu, 2012-04-12 at 08:05 -0700, Kees Cook wrote:
Please just use Yama -- it's already in the mainline kernel[1]. You
don't need to create anything new. All the crash handlers and other
tools (Firefox, Chrome, DrKonqi/KDE, and Wine) are already aware of how
to declare ptrace relationships
Hi,
On Thu, Apr 12, 2012 at 05:18:59PM +0200, Mark Wielaard wrote:
On Thu, 2012-04-12 at 08:05 -0700, Kees Cook wrote:
Please just use Yama -- it's already in the mainline kernel[1]. You
don't need to create anything new. All the crash handlers and other
tools (Firefox, Chrome,
On 04/12/2012 02:39 PM, Mark Wielaard wrote:
On Mon, Apr 09, 2012 at 09:38:40AM -0400, Eric Paris wrote:
(Think about it a moment. gdb -p is the same as firefox trying to ptrace
gnome-keyring)
I thought a bit about it. And now I am even more confused :)
It seems you are already not
On Tue, 2012-04-10 at 14:04 +0100, Matthew Garrett wrote:
Option 2: Disable ptrace for everything except direct child processes.
Allows the common case of running a task directly under a tool like gdb
or strace, but forbids attaching one to an already running task. May
break some of the
On Mon, Apr 09, 2012 at 12:08:13PM +0200, Matej Cepl wrote:
On 8.4.2012 22:50, Tom Lane wrote:
And, as I said, the alternative is that this gets turned off, by me
and probably a very large fraction of other Fedora users.
Without getting into this discussion much, I would just note a bit
of
On Wed, Apr 11, 2012 at 03:58:55PM +0200, Mark Wielaard wrote:
On Tue, 2012-04-10 at 14:04 +0100, Matthew Garrett wrote:
Option 2: Disable ptrace for everything except direct child processes.
Allows the common case of running a task directly under a tool like gdb
or strace, but forbids
On 04/11/2012 10:21 AM, Matthew Garrett wrote:
On Wed, Apr 11, 2012 at 03:58:55PM +0200, Mark Wielaard wrote:
On Tue, 2012-04-10 at 14:04 +0100, Matthew Garrett wrote:
Option 2: Disable ptrace for everything except direct child processes.
Allows the common case of running a task directly
On 04/11/2012 05:19 PM, Richard W.M. Jones wrote:
On Mon, Apr 09, 2012 at 12:08:13PM +0200, Matej Cepl wrote:
On 8.4.2012 22:50, Tom Lane wrote:
And, as I said, the alternative is that this gets turned off, by me
and probably a very large fraction of other Fedora users.
Without getting into
On Wed, 11 Apr 2012, Kalev Lember wrote:
This is the reason why I find it important to make the life as good as
possible for the power users / developers / enthusiasts: when the they
like using Fedora and developing software with Fedora, they're likely to
also invite other people to try Fedora
On Tue, 10 Apr 2012 04:41:46 +0200, Kevin Kofler wrote:
Mozilla plugins is usually a euphemism for proprietary crap, most often
Flash. We cannot package that in Fedora.
So if there is the easy installability of proprietary crap like Mozilla
plugins why aren't also the repositories like
On 9.4.2012 22:55, Daniel J Walsh wrote:
DrKonqi are, we
should disable the ability of any process on their desktop from being able to
read/manipulate other processes on their desktop.
This is actually IMHO a mistake ... DrKonqi (KDE version of abrt-gui) is
exactly for people who have no clue
On 10.4.2012 08:04, Jan Kratochvil wrote:
So if there is the easy installability of proprietary crap like Mozilla
plugins why aren't also the repositories like RPMforge pre-configured
automatically? What is the difference between RPMforge and Mozilla plugins
database?
a) there is no
Le mardi 10 avril 2012 à 02:57 +0100, Matthew Garrett a écrit :
On Mon, Apr 09, 2012 at 09:18:13PM -0400, Daniel J Walsh wrote:
On 04/09/2012 05:06 PM, Matthew Garrett wrote:
On Mon, Apr 09, 2012 at 04:55:27PM -0400, Daniel J Walsh wrote:
And guess what I use these tools, and I just
On 9.4.2012 16:06, Jan Kratochvil wrote:
Wouldn't it be better to package Mozilla plugins in Fedora so that they are
trusted? And then disable Firefox plugins downloads the same way as there is
Firefox updater disabled (--disable-updater) as it would conflict/duplicate
the rpm packaging of
On Tue, Apr 10, 2012 at 11:32 AM, Matej Cepl mc...@redhat.com wrote:
On 9.4.2012 16:06, Jan Kratochvil wrote:
Wouldn't it be better to package Mozilla plugins in Fedora so that they
are
trusted? And then disable Firefox plugins downloads the same way as there
is
Firefox updater disabled
On Tue, 10 Apr 2012 11:40:14 +0200, drago01 wrote:
rpm packages do not magically fix security issues. A vulnerability in
a plugin can be exploited by an attacker regardless how the plugin got
installed. (rpm or not).
This is still unrelated to the point whether Fedora is a Free distro or not
On Tue, 10 Apr 2012 11:32:38 +0200, Matej Cepl wrote:
Yes, it would be nice ... except there are so many addons to package
Fedora also does not have about 2 packages that Debian has. Does it mean
we should give up on Fedora and switch to Debian because we would have to make
2 packages
On Tue, 10 Apr 2012 11:37:58 +0200, drago01 wrote:
We don't even have a package installation gui that does not suck i.e
is usable for most users.
Going to a website and click install this addon is way easier from a
users pov.
Keeping pre-installed MS-Windows on the computer is also way
On 04/09/2012 10:00 PM, Kevin Kofler wrote:
Daniel J Walsh wrote:
We already block ptrace from almost every confined domain other then
user domains.
Then why not just keep it that way instead of breaking GDB?
Kevin Kofler
Because we are trying to protect the logged in user, where we
On 04/09/2012 09:58 PM, Kevin Kofler wrote:
Matej Cepl wrote:
I am afraid you are not an ordinary Fedora user. If abrt/breakpad/etc.
works as they should, then I don't think majority of Fedora users have
any reason why to pull out gdb at all.
Because DrKonqi or some other similar crash
On Tue, 2012-04-10 at 04:04 +0200, Kevin Kofler wrote:
Matej Cepl wrote:
OK, this is bad ... is it just because somebody ignored DrKonqi (which
would be very bad indeed) or are abrt and breakpad also affected?
If Breakpad attaches GDB to live processes as DrKonqi does, it's also
Kevin Kofler píše v Út 10. 04. 2012 v 14:47 +0200:
Daniel J Walsh wrote:
I have seen of gdm and NetworkManager execing gdb on crash. You keep
saying other apps work like DrKonqi, can you give examples?
While unfortunately I don't know how all these work (i.e. whether they also
work by
Simo Sorce wrote:
Abrt looks clearly a better solution.
I disagree.
From a technical standpoint, working on core files means you have to dump
core and then attach to the core file after the fact when you could just
backtrace right when the crash happened. A waste of disk space, and a
Matej Cepl wrote:
One good thing I would say about abrt is that it highly modular. Would
output plugin file-the-bug-to-bugs.kde.org-or-somewhere-else be a
solution for you? After all filing to bugzilla.redhat.com is just a
matter of setting plugin for it
ABRT does not have access to the
On Tue, Apr 10, 2012 at 11:27:12AM +0200, Michael Scherer wrote:
Le mardi 10 avril 2012 à 02:57 +0100, Matthew Garrett a écrit :
Ok, so if anything that's already a likely target of attack is unable to
initiate ptrace or start a process that can ptrace, what real extra
security do we gain
Jan Kratochvil wrote:
This is still unrelated to the point whether Fedora is a Free distro or
not (it is not due to Linux firmwares - this part is known). So why isn't
Flash + acroread etc. also installed by default or be available in
repositories?
Because Fedora IS a Free Software
drago01 wrote:
We don't even have a package installation gui that does not suck i.e
is usable for most users.
Neither gnome-packagekit nor Apper suck. They're perfectly usable for most
users. We just have a vocal minority of users who grew so accustomed to
using the yum command line that they
On Tue, 10 Apr 2012 15:07:45 +0200, Kevin Kofler wrote:
Jan Kratochvil wrote:
This is still unrelated to the point whether Fedora is a Free distro or
not (it is not due to Linux firmwares - this part is known). So why isn't
Flash + acroread etc. also installed by default or be available in
On 04/09/2012 08:22 PM, Daniel J Walsh wrote:
On 04/09/2012 02:15 PM, Miloslav Trmač wrote:
On Mon, Apr 9, 2012 at 4:58 PM, Daniel J Walshdwa...@redhat.com wrote:
One suggestion I have heard is to turn the feature off if someone install
gdb like we do with DrKonji, which might be a better
On 04/10/2012 09:24 AM, Jan Kratochvil wrote:
On Tue, 10 Apr 2012 15:07:45 +0200, Kevin Kofler wrote:
Jan Kratochvil wrote:
This is still unrelated to the point whether Fedora is a Free distro
or not (it is not due to Linux firmwares - this part is known). So why
isn't Flash + acroread etc.
On Tue, 10 Apr 2012, Kevin Kofler wrote:
From a technical standpoint, working on core files means you have to dump
core and then attach to the core file after the fact when you could just
backtrace right when the crash happened. A waste of disk space, and a
security risk (you're making RAM
On Tue, 10 Apr 2012, drago01 wrote:
Wouldn't it be better to package Mozilla plugins in Fedora so that they are
trusted?
rpm packages do not magically fix security issues. A vulnerability in
a plugin can be exploited by an attacker regardless how the plugin got
installed. (rpm or not).
On Tue, Apr 10, 2012 at 11:26:50AM -0300, Horst H. von Brand wrote:
Matthew Garrett mj...@srcf.ucam.org wrote:
[...]
To a first approximation, simply auditing the distribution for anything
that opens files or reads information from the network and forbidding
them ptrace access (and
Hi Dan,
On Mon, Apr 09, 2012 at 10:58:43AM -0400, Daniel J Walsh wrote:
I thought I made this clear in my blogs and the feature page that I wanted
this on deny_ptrace on by default.
[...]
We did have a bug in Alpha where it was turned off. Now that people are
actually seeing it turned on in
On Tue, Apr 10, 2012 at 4:29 PM, Paul Wouters pwout...@redhat.com wrote:
On Tue, 10 Apr 2012, drago01 wrote:
Wouldn't it be better to package Mozilla plugins in Fedora so that they
are
trusted?
rpm packages do not magically fix security issues. A vulnerability in
a plugin can be exploited
On 04/10/2012 09:04 AM, Matthew Garrett wrote:
On Tue, Apr 10, 2012 at 11:27:12AM +0200, Michael Scherer wrote:
Le mardi 10 avril 2012 à 02:57 +0100, Matthew Garrett a écrit :
Ok, so if anything that's already a likely target of attack is unable
to initiate ptrace or start a process that can
Niels de Vos wrote:
It seems that there is prctl() call to allow a specific PID (like gdb
stared by the signal-handler of DrKonqi) to trace the calling/crached
process. The idea comes from following the gdb discussion here:
- http://sourceware.org/ml/gdb-patches/2012-03/msg00274.html
Indeed,
Mark Wielaard wrote:
On Mon, Apr 09, 2012 at 10:58:43AM -0400, Daniel J Walsh wrote:
I thought I made this clear in my blogs and the feature page that I wanted
this on deny_ptrace on by default.
[...]
We did have a bug in Alpha where it was turned off. Now that people are
actually seeing it
Paul Wouters wrote:
I have been upstream for openswan for about 8 years, and I can tell you
that the single reason for reporting bugs to upstream is if they really
need to get openswan working and they can't. At most, they report
straight into the RHBZ without ever bothering to contact
On 04/10/2012 11:08 AM, drago01 wrote:
On Tue, Apr 10, 2012 at 4:29 PM, Paul Wouters pwout...@redhat.com wrote:
On Tue, 10 Apr 2012, drago01 wrote:
Wouldn't it be better to package Mozilla plugins in Fedora so that
they are trusted?
rpm packages do not magically fix security issues. A
On Tue, Apr 10, 2012 at 11:12:48AM -0400, Daniel J Walsh wrote:
The problem with option 4 is that it is very difficult to do since the desktop
is so connected. Say we isolate firefox_t as the same as unconfined_t without
ptrace.
Unless an app is current confined, I don't think there's a real
On Tue, Apr 10, 2012 at 07:47:25AM -0400, Daniel J Walsh wrote:
Because we are trying to protect the logged in user, where we currently do not
confine that many domains, and even if you are using confined users we do not
prevent a confined user process from ptrace on another user process,
On 8.4.2012 22:50, Tom Lane wrote:
And, as I said, the alternative is that this gets turned off, by me
and probably a very large fraction of other Fedora users.
Without getting into this discussion much, I would just note a bit of
shocking news for you ... I am afraid you are not an ordinary
On 9.4.2012 00:31, Kevin Kofler wrote:
+1, this broken misfeature really needs to be turned off by default. It also
breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by
OK, this is bad ... is it just because somebody ignored DrKonqi (which
would be very bad indeed) or
Matej Cepl wrote:
On 9.4.2012 00:31, Kevin Kofler wrote:
+1, this broken misfeature really needs to be turned off by default. It
also breaks crash reporters such as DrKonqi (for DrKonqi, we work around
this by
OK, this is bad ... is it just because somebody ignored DrKonqi (which
would be
On Sun, Apr 08, 2012 at 07:02:31PM +0200, Mark Wielaard wrote:
Previously https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
implied that this feature could be turned on by an administrator,
but recently it was changed to be on by default. Was that intended?
The change to
On Mon, 2012-04-09 at 00:31 +0200, Kevin Kofler wrote:
It also
breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by
disabling the flag in kde-runtime's %post script, but there are other
similar debuggers in upstream software, some not packaged in Fedora)
I ask in the
On 04/09/2012 11:11 AM, Frank Ch. Eigler wrote:
dwalsh wrote:
I thought I made this clear in my blogs and the feature page that I
wanted this on deny_ptrace on by default. [...]
https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
The version of this page that you last edited [1]
On Mon, 09 Apr 2012 17:56:06 +0200, Paul Wouters wrote:
Only if you man the helpdesk for answering why users cannot install
adblock in firefox.
Do you mean mozilla-adblockplus-1.3.10-4.fc16.noarch? And if it is so wanted
feature let it be installed in default Fedora installation and nobody will
2012/4/9 Daniel J Walsh dwa...@redhat.com
On 04/09/2012 11:11 AM, Frank Ch. Eigler wrote:
dwalsh wrote:
I thought I made this clear in my blogs and the feature page that I
wanted this on deny_ptrace on by default. [...]
https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
On Mon, Apr 9, 2012 at 4:58 PM, Daniel J Walsh dwa...@redhat.com wrote:
One suggestion I have heard is to turn the feature off if someone install gdb
like we do with DrKonji, which might be a better solution then disabling by
default.
It would be very surprising if merely installing a package
On 04/09/2012 02:15 PM, Miloslav Trmač wrote:
On Mon, Apr 9, 2012 at 4:58 PM, Daniel J Walsh dwa...@redhat.com wrote:
One suggestion I have heard is to turn the feature off if someone install
gdb like we do with DrKonji, which might be a better solution then
disabling by default.
It would be
On Mon, Apr 9, 2012 at 3:38 PM, Eric Paris epa...@redhat.com wrote:
On Mon, 2012-04-09 at 00:31 +0200, Kevin Kofler wrote:
It also
breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by
disabling the flag in kde-runtime's %post script, but there are other
similar
On 04/09/2012 07:58 AM, Daniel J Walsh wrote:
As I have stated in the blogs, this would be sad, since the goal of this
feature is to protect the people who would never execute gdb -p, don't even
know what gdb is. IE The vast majority of computer users. So we will make
the system insecure
John Reiser wrote:
I reasonably require gdb -p pid (PTRACE_ATTACH) to work. If you want
to protect people, then figure out some way to protect them yet allow me
to do my work on a usual multi-user system.
They have figured out a way: It's controlled by a boolean.
You can disable (or enable)
On 04/09/2012 06:08 AM, Matej Cepl wrote:
Without getting into this discussion much, I would just note a bit of
shocking news for you ... I am afraid you are not an ordinary Fedora
user. If abrt/breakpad/etc. works as they should, then I don't think
majority of Fedora users have any reason why
On 04/09/2012 04:11 PM, Przemek Klosowski wrote:
On 04/09/2012 06:08 AM, Matej Cepl wrote:
Without getting into this discussion much, I would just note a bit of
shocking news for you ... I am afraid you are not an ordinary Fedora
user. If abrt/breakpad/etc. works as they should, then I
On Mon, Apr 09, 2012 at 04:55:27PM -0400, Daniel J Walsh wrote:
And guess what I use these tools, and I just execute setsebool deny_ptrace 0
anytime I need to strace or debug an application, then I turn it back on when
I am done.
Are we able to determine that strace or gdb have been
On 04/09/2012 05:06 PM, Matthew Garrett wrote:
On Mon, Apr 09, 2012 at 04:55:27PM -0400, Daniel J Walsh wrote:
And guess what I use these tools, and I just execute setsebool
deny_ptrace 0 anytime I need to strace or debug an application, then I
turn it back on when I am done.
Are we able
Daniel J Walsh wrote:
We already block ptrace from almost every confined domain other then user
domains.
Then why not just keep it that way instead of breaking GDB?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Matej Cepl wrote:
OK, this is bad ... is it just because somebody ignored DrKonqi (which
would be very bad indeed) or are abrt and breakpad also affected?
If Breakpad attaches GDB to live processes as DrKonqi does, it's also
affected. As Rex said, ABRT is not affected because it attaches to
Daniel J Walsh wrote:
My argument is if you understand what ptrace or gdb are, you probably can
figure out how to turn this feature off. And we are even putting
information into the commands to tell you how to disable it. But for the
vast majority of computer users who would what the hell
Eric Paris wrote:
I ask in the bug how DrKonqi works on other distros with the YAMA
security module enabled which implements a slightly different semantic
and didn't hear a response.
AFAIK, Kubuntu disables DrKonqi entirely, using Apport instead. But we don't
want to do the same with ABRT in
Daniel J Walsh wrote:
We did have a bug in Alpha where it was turned off. Now that people are
actually seeing it turned on in Fedora 17 Beta, they are reacting.
Uh no, I reacted back when you announced you would turn it on (which was
also the first time I heard of the feature in the first
Michael Cronenworth wrote:
John Reiser wrote:
I reasonably require gdb -p pid (PTRACE_ATTACH) to work. If you want
to protect people, then figure out some way to protect them yet allow
me to do my work on a usual multi-user system.
They have figured out a way: It's controlled by a boolean.
Hi,
I recently tested out f17 and saw I can no longer trace or debug
applications by default. While I appreciate why one might want
some applications to not ptrace any other application, it is a
bit of a sledge hammer to deny any and all program introspection.
Previously
Mark Wielaard m...@redhat.com writes:
Previously https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
implied that this feature could be turned on by an administrator,
but recently it was changed to be on by default. Was that intended?
I certainly hope that's a mistake. If it's not, I
I recently tested out f17 and saw I can no longer trace or debug
applications by default. ...
Is there still time to discuss and/or reconsider turning this on by
default for F17?
According to this bugzilla Comment
https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27
Fedora 17 Alpha
John Reiser jrei...@bitwagon.com writes:
gdb nicely gives the work-around for denyPtrace, but the work-around
requires privileges to implement. So far the implementation history
of the denyPtrace feature leads me to fear loss of Functionality and
Usability for software developers.
Indeed.
John Reiser jrei...@bitwagon.com writes:
[...]
According to this bugzilla Comment
https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27
Fedora 17 Alpha turned on denyPtrace (as default) by mistake.
That's not how I read #c27. The flag was turned off during alpha by
mistake and that it
Mark Wielaard wrote:
Is there still time to discuss and/or reconsider turning this on by
default for F17?
+1, this broken misfeature really needs to be turned off by default. It also
breaks crash reporters such as DrKonqi (for DrKonqi, we work around this by
disabling the flag in
On Sun, Apr 8, 2012 at 10:50 PM, Tom Lane t...@redhat.com wrote:
And, as I said, the alternative is that this gets turned off, by me
and probably a very large fraction of other Fedora users. How is
that more secure?
Perhaps people installing servers in high-risk situations could just
not turn
On Sun, 08 Apr 2012 22:50:21 +0200, Tom Lane wrote:
A possible compromise that might allow software developers to live
with the setting would be if the default excluded gdb
Counterargument in some that Bug was then the attacker can spawn GDB instead
of using PTRACE_ATTACH in that process
80 matches
Mail list logo
