[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80413.1228427770@turing-police.cc.vt.edu>
Date: Thu, 04 Dec 2008 16:56:10 -0500
From: Valdis.Kletnieks@...edu
To: Geoffrey McRae <geoff@...idhost.com>
Cc: Peter Teoh <htmldeveloper@...il.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Nick Andrew <nick@...k-andrew.net>,
linux-kernel@...r.kernel.org
Subject: Re: New Security Features, Please Comment
On Thu, 04 Dec 2008 10:40:56 +1100, Geoffrey McRae said:
> Ok, so this is a pretty major flaw of the idea, thats why I put this
> concept out there, any suggestions as to how to get around this?
> Possibly add some checking to disable certain functions in the child
> when the enable_setpresuid function has been called?.
Or just deploy SELinux instead.
> Or save the signal handlers the first time setpresuid is called, and the
> next time, restore them so if the child has changed them, they get
> re-set back to their initial state?
It's not just signal handlers.
while (getpid()) msleep(1);
/* malicious code here */
Just loop, pop up every few milliseconds and check if you're root,
and fall out of the loop and go into attack mode if you are.
If you're using it to toggle between various non-root userids, just adjust
the while accordingly: 'while ((me = getpid()) != 497) ...' or whatever
you need.
And if you try to disable getpid to prevent that attack, consider something
that does this:
while (open("only_creatable_by_target_uid",O_CREAT) < 0)
You can hardly take open() away from processes. ;)
> I know many people are against the idea of adding new functions at will
> to the kernel, thats why I am trying to flesh out all the potential
> problems and find solutions to them first.
We don't mind adding functions. We just hate broken-by-design functions.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists