On Wed, Apr 30, 2008 at 10:46:29AM +0200, Martin Pitt wrote:
> Josselin Mouette [2008-04-30 10:17 +0200]:
> > This looks indeed like a reasonable alternative if we don't get the
> > noptrace group ; it would be easy to patch gksu/gnome-keyring/... with
> > the same stuff.
>
> I agree, and give the
On Sun, Apr 27, 2008 at 06:22:38PM +0200, Florian Weimer wrote:
> * Josselin Mouette:
> > Given that it seems unlikely that we obtain another solution, should we
> > start right now with that stuff?
> I think it's a bit foolish to abuse SGID bits to take away permissions.
> This kind of restrict
Josselin Mouette [2008-04-30 10:17 +0200]:
> This looks indeed like a reasonable alternative if we don't get the
> noptrace group ; it would be easy to patch gksu/gnome-keyring/... with
> the same stuff.
I agree, and give the other possible attack scenarios it doesn't make
much sense to throw a lo
Le lundi 28 avril 2008 à 09:28 +0200, Martin Pitt a écrit :
> Martin Pitt [2008-04-28 9:22 +0200]:
> > That's what the current Ubuntu version of libpolkit does (patch
> > attached FYI).
This looks indeed like a reasonable alternative if we don't get the
noptrace group ; it would be easy to patch
Martin Pitt <[EMAIL PROTECTED]> writes:
> In the end I did not worry too much about the startup race condition.
> If there is already a Trojan in the user's session, it is trivial to
> circumvent PR_SET_DUMPABLE, of course (by running the target
> application through gdb right from the start). But
On Fri, Dec 7, 2007 at 2:18 PM, Martin Pitt <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> one thing that has bothered me for a long time already is the
> complete lack of a security boundary between processes of the same
> user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
> default
Martin Pitt [2008-04-28 9:22 +0200]:
> That's what the current Ubuntu version of libpolkit does (patch
> attached FYI).
*cough*
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
# Description: Disable ptrace() an
Colin Watson [2008-04-27 13:19 +0100]:
> > Can't you do something against ptrace in the binary itself and only
> > for critical sections?
>
> You can (use prctl() to disable PR_SET_DUMPABLE), but it's only checked
> on ptrace_attach so that would be racy.
That's what the current Ubuntu version of
"brian m. carlson" <[EMAIL PROTECTED]> writes:
> On Mon, Apr 28, 2008 at 12:51:48AM +0200, Thomas Viehmann wrote:
> 1) it came from Debian, in which case I suggest we handle that program
> like micq (which had a malicious upstream); or
> 2) I wrote it myself, in which case I obviously designed it
On Mon, Apr 28, 2008 at 12:51:48AM +0200, Thomas Viehmann wrote:
Colin Watson wrote:
I think it was my suggestion to Martin in the first place, so no, I
don't have any objection. :-) I haven't been following the thread,
though - has there been general consensus on this?
I must say that the thr
Colin Watson wrote:
I think it was my suggestion to Martin in the first place, so no, I
don't have any objection. :-) I haven't been following the thread,
though - has there been general consensus on this?
I must say that the thread did not do much to convince me.[1]
Kind regards
T.
1. http:
* Josselin Mouette:
> Given that it seems unlikely that we obtain another solution, should we
> start right now with that stuff?
I think it's a bit foolish to abuse SGID bits to take away permissions.
This kind of restriction is essentially a configuration option, and
applying it to the wrong pr
Colin Watson <[EMAIL PROTECTED]> writes:
> On Sun, Apr 27, 2008 at 12:56:28PM +0200, Goswin von Brederlow wrote:
>> No idea how to prevent LD_PRELOAD and people could always use their
>> own linker to ignore the sgid bit anyway.
>
> If they want to deliberately start a program with reduced protect
On Sun, Apr 27, 2008 at 12:56:28PM +0200, Goswin von Brederlow wrote:
> Josselin Mouette <[EMAIL PROTECTED]> writes:
> > Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
> >> one thing that has bothered me for a long time already is the
> >> complete lack of a security boundary bet
On Sun, Apr 27, 2008 at 10:52:38AM +0200, Josselin Mouette wrote:
> Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
> > one thing that has bothered me for a long time already is the
> > complete lack of a security boundary between processes of the same
> > user. Things like LD_PRE
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
>> Hi all,
>>
>> one thing that has bothered me for a long time already is the
>> complete lack of a security boundary between processes of the same
>> user. Things like LD_PRELOAD and
Le vendredi 07 décembre 2007 à 19:18 +0100, Martin Pitt a écrit :
> Hi all,
>
> one thing that has bothered me for a long time already is the
> complete lack of a security boundary between processes of the same
> user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
> default for all
[Martin Pitt]
> What do you think about this approach? I'm well aware that this
> alone won't rescue desktop security (getting there is looots of more
> work), but one has to start somewhere.
Would it break fakeroot and other tools using LD_PRELOAD to get the
wanted effect?
Happy hacking,
--
Pe
Hi,
Aaron M. Ucko [2007-12-10 12:32 -0500]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
>
> > That would be ideal, of course. Does ELF support anything like that?
>
> AFAICT, it should be possible to use a custom .note.* or .gnu.*
> section for such purposes. I'm not an ELF expert, though.
I dro
Hi Martin,
Martin Pitt wrote:
> One easy solution that comes to my mind is to install those affected
> programs setgid, and drop the additional group immediately after
> program start with setgid(getgid()). For this we should introduce a
> new static group into base-passwd, like "noptrace", to not
Martin Pitt <[EMAIL PROTECTED]> writes:
> That would be ideal, of course. Does ELF support anything like that?
AFAICT, it should be possible to use a custom .note.* or .gnu.*
section for such purposes. I'm not an ELF expert, though.
> P.S. Please honour m-f-t, thanks.
Sorry about that; I read
Hi,
Aaron M. Ucko:
> I would counter-propose introducing some sort of ELF tag that ld could
> set and the kernel and ld.so could check; while this would be more
> involved, it would be less hackish and would avoid introducing new
> potential vulnerabilities.
That would be ideal, of course. Does E
On Fri, Dec 07, 2007 at 07:18:11PM +0100, Martin Pitt wrote:
> However, a lot of programs that we have deal with passwords and other
> secrets which deserve some protection, like passwords you type into
> ssh, screensavers, seahorse, etc.
While I sort of like the idea, I must admit that if I could
Steve Langasek <[EMAIL PROTECTED]> writes:
> There are no extra privileges; noptrace is intended to be a group that owns
> no files other than the sgid binaries, can write to none of them, contains
> no users, is unable to ptrace any other processes that it couldn't already,
> and doesn't grant pr
On Fri, Dec 07, 2007 at 07:18:11PM +0100, Martin Pitt wrote:
> What do you think about this approach? I'm well aware that this alone
> won't rescue desktop security (getting there is looots of more work),
> but one has to start somewhere.
I'm not particularly fussed about the race conditions invol
On Sat, Dec 08, 2007 at 05:01:27PM -0500, Aaron M. Ucko wrote:
> Although this is an interesting idea, I have misgivings about running
> even temporarily with any sort of extra privileges; C++ executables in
> particular may run a fair bit of code from static objects'
> constructors before main() e
Although this is an interesting idea, I have misgivings about running
even temporarily with any sort of extra privileges; C++ executables in
particular may run a fair bit of code from static objects'
constructors before main() ever starts.
I would counter-propose introducing some sort of ELF tag t
27 matches
Mail list logo
