linux.kernel - 26 new messages in 9 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* RFC: disablenetwork facility. (v4) - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/b10d3d92ccc2351e?hl=en
* Computer becomes unusable without any apparent reason - 4 messages, 4
authors
http://groups.google.com/group/linux.kernel/t/bc5bd6b0e7f64ba0?hl=en
* tracing: Use defined fields and print_fmt to print formats - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/1cad27373a1dc60b?hl=en
* reiserfs: inconsistent lock state - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/b237721af048d1f7?hl=en
* [GIT PULL][v2.6.33] tracing: consolidate print fmt - 10 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e7b9b203270e928c?hl=en
* amso1100/c2_provider.c: use %pM to shown MAC address - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/59ef38c32b3ad284?hl=en
* input: imon driver for SoundGraph iMON/Antec Veris IR devices - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/0101690f6ce5a3f9?hl=en
* 2.6.32 seemed to have broken nVidia MCP7A sata controller - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e08b9ffda4b7db69?hl=en
* sky2 panic in 2.6.32.1 under load (new oops) - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/8e6b471b3077e37d?hl=en

==============================================================================
TOPIC: RFC: disablenetwork facility. (v4)
http://groups.google.com/group/linux.kernel/t/b10d3d92ccc2351e?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Dec 29 2009 8:10 am
From: Bryan Donlan

On Tue, Dec 29, 2009 at 10:11 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> Eric, let me specifically point out a 'disable setuid-root'
> problem on linux: root still owns most of the system even when
> it's not privileged. �So does "disable setuid-root" mean
> we don't allow exec of setuid-root binaries at all, or that
> we don't setuid to root, or that we just don't raise privileges
> for setuid-root?

I, for one, think it would be best to handle it exactly like the
nosuid mount option - that is, pretend the file doesn't have any
setuid bits set. There's no reason to deny execution; if the process
would otherwise be able to execute it, it can also copy the file to
make a non-suid version and execute that instead. And some programs
can operate with reduced function without setuid. For example, screen
comes to mind; it needs root to share screen sessions between multiple
users, but can operate for a single user just fine without root, and
indeed the latter is usually the default configuration.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Tues, Dec 29 2009 8:30 am
From: Michael Stone

Serge Hallyn writes:
> Quoting Michael Stone (michael@laptop.org):
> So far, two defaults have been proposed:
>
> default-deny incompatible isolation (Pavel)
> default-permit incompatible isolation (Michael)
>
> So far, several signalling mechanisms have been proposed:
>
>> 1) enabling a kernel config option implies default-permit
>>
>> - My favorite; apparently insufficient for Pavel?
>
> default under what conditions? any setuid? setuid-root?

My favorite option is that CONFIGURE_SECURITY_DISABLENETWORK causes
disablenetwork to function like djb describes: unprivileged and irrevocable.

(I don't have any setuid executables that I'm worried about breaking; only ones
that I think /should/ be broken and aren't, like ping.)

> 2) default-deny; disablesuid grants disablenetwork
>
> - "disablesuid" is my name for the idea of dropping the privilege of
> exec'ing setuid binaries
>
> - Suggested by Pavel and supported by several others.
>
> - I think it has the same backwards-compatibility problem as
> disablenetwork: disablesuid is an isolation primitive.
>
> 3) default-deny; dropping a capability from the bounding set grants "permit"
>
> - Suggested by Serge; seems nicely fine-grained but rather indirect
>
> Actually I think it's the opposite of what you said here: so long as the
> capability is in pE, you can regain network. So it would require a privileged
> process early on (like init or login) to remove the capability from the
> bounding set (bc doing so requires CAP_SETPCAP), but once that was done,
> the resulting process and it's children could not require the capability,
> and, without the capability, could not regain network. Point being that
> privileged userspace had to actively allow userspace to trap a setuid root
> binary without networking.

What I wrote accurately (if confusingly; sorry!) reflects what you suggest: by
default, the kernel should deny processes from irrevocably dropping networking
privilege until signalled that this is acceptable by the privileged mechanism
of dropping your cap from the bounding set.

> I think during exec we can simply check for this capability in pE, and
> if present then re-enable network if turned off. Then setuid-root binaries
> will raise that bit (if it's in the bounding set) automatically. Now,
> that means setuid-nonroot binaries will not reset network. Though you
> could make that happen by doing setcap cap_net_allownet+pe /the/file.
> Does that suffice?

I think I could live with it.

I find it weird that, if I call disablenetwork on a system *without* dropping
your capability, sendto(...) will fail but execve(['/bin/ping', '...']) will
succeed.

Still, it will do what I need.

>> 4) default-deny; setting a sysctl implies permit
>>
>> - Suggested by Serge; works fine for me
>
>That still leaves the question of when we re-allow network. Any
>setuid?

My intention was that prctl(PR_SET_NETWORK, PR_NETWORK_OFF) would return
-ENOTSUP or similar until the sysctl was enabled, at which point it would work
as I specified.

("As I specified" means one of "irrevocable" or "like rlimits; can be relaxed
by explicit action by privileged processes")

>> P.P.S. - On a completely unrelated note: imagine trying to use SELinux (or your
>> favorite MAC framework) to restrict the use of prctl(PR_SET_NETWORK,
>> PR_NETWORK_OFF). Am I right that sys_prctl() contains a
>> time-of-check-to-time-of-use (TOCTTOU) race (with security_task_prctl() as the
>> check and with prctl_set_network() as the use) as a result of the actual
>> argument being passed by address rather than by value?
>
> I'm probably misunderstanding your question, but just in case I'm not: the
> answer is that you wouldn't use the prctl interface anyway. You would strictly
> use domain transitions. Instead of doing prctl(PR_SET_NETWORK, PR_NETWORK_OFF)
> you would move yourself from the user_u:user_r:network_allowed domain to the
> user_u:user_r:network_disallowed domain.

You misunderstood; sorry I wasn't more clear. :)

I was really saying:

Suppose process A and process B create a share a memory segment containing an
unsigned long pointed to by.

unsigned long *flags;

Can't process A call prctl(PR_SET_NETWORK, flags) while, on another
processor, process B is twiddling bits in *flags so that

security_task_prctl() sees the bits that process A wrote and
prctl_set_network() sees the bits that process B wrote?

i.e. isn't there a TOCTTOU race [1] here in every prctl option that uses a
pointer argument? if not, what stops the race?

Regards,

Michael

[1]: http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 4 ==
Date: Tues, Dec 29 2009 8:40 am
From: "Serge E. Hallyn"

Quoting Bryan Donlan (bdonlan@gmail.com):
> On Tue, Dec 29, 2009 at 10:11 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> > Eric, let me specifically point out a 'disable setuid-root'
> > problem on linux: root still owns most of the system even when
> > it's not privileged. �So does "disable setuid-root" mean
> > we don't allow exec of setuid-root binaries at all, or that
> > we don't setuid to root, or that we just don't raise privileges
> > for setuid-root?
>
> I, for one, think it would be best to handle it exactly like the
> nosuid mount option - that is, pretend the file doesn't have any
> setuid bits set. There's no reason to deny execution; if the process
> would otherwise be able to execute it, it can also copy the file to
> make a non-suid version and execute that instead. And some programs
> can operate with reduced function without setuid. For example, screen
> comes to mind; it needs root to share screen sessions between multiple
> users, but can operate for a single user just fine without root, and
> indeed the latter is usually the default configuration.

That's fine with me, seems safe for a fully unprivileged program to
use, and would make sense to do through one of the securebits set
with prctl(PR_SET_SECUREBITS).

In addition, I assume we would also refuse to honor file capabilities?

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 4 ==
Date: Tues, Dec 29 2009 9:10 am
From: Bryan Donlan

On Tue, Dec 29, 2009 at 11:39 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> Quoting Bryan Donlan (bdonlan@gmail.com):
>> On Tue, Dec 29, 2009 at 10:11 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
>> > Eric, let me specifically point out a 'disable setuid-root'
>> > problem on linux: root still owns most of the system even when
>> > it's not privileged. �So does "disable setuid-root" mean
>> > we don't allow exec of setuid-root binaries at all, or that
>> > we don't setuid to root, or that we just don't raise privileges
>> > for setuid-root?
>>
>> I, for one, think it would be best to handle it exactly like the
>> nosuid mount option - that is, pretend the file doesn't have any
>> setuid bits set. There's no reason to deny execution; if the process
>> would otherwise be able to execute it, it can also copy the file to
>> make a non-suid version and execute that instead. And some programs
>> can operate with reduced function without setuid. For example, screen
>> comes to mind; it needs root to share screen sessions between multiple
>> users, but can operate for a single user just fine without root, and
>> indeed the latter is usually the default configuration.
>
> That's fine with me, seems safe for a fully unprivileged program to
> use, and would make sense to do through one of the securebits set
> with prctl(PR_SET_SECUREBITS).
>
> In addition, I assume we would also refuse to honor file capabilities?

Yes - essentially a one-time switch saying "never allow me to gain
capabilities again".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Computer becomes unusable without any apparent reason
http://groups.google.com/group/linux.kernel/t/bc5bd6b0e7f64ba0?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Dec 29 2009 8:20 am
From: Luís Picciochi Oliveira

Hi,
The bug is present on 2.6.32 and subsequent versions (2.6.32.1, 2.6.32.2).
It has been resolved as of 2.6.33-rc1.

Regards,
Lu�s Picciochi

On Tue, Dec 29, 2009 at 3:28 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.31 and 2.6.32.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.31 and 2.6.32. �Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry � � � : http://bugzilla.kernel.org/show_bug.cgi?id=14436
> Subject � � � � : Computer becomes unusable without any apparent reason
> Submitter � � � : Pitxyoki <Pitxyoki@gmail.com>
> Date � � � � � �: 2009-10-18 18:32 (73 days old)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Tues, Dec 29 2009 8:40 am
From: Peter Zijlstra

On Tue, 2009-12-29 at 16:28 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.31 and 2.6.32.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.31 and 2.6.32. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14630
> Subject : sched_rt_periodic_timer vs cpu hotplug
> Submitter : Heiko Carstens <heiko.carstens@de.ibm.com>
> Date : 2009-11-11 10:18 (49 days old)
> References : http://marc.info/?l=linux-kernel&m=125793470309588&w=4
> Handled-By : Peter Zijlstra <peterz@infradead.org>
> Patch : http://patchwork.kernel.org/patch/60250/

git branch -a --contains 047106ad

seems to suggest that this made it to Linus' tree.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 4 ==
Date: Tues, Dec 29 2009 8:40 am
From: Evgeniy Polyakov

On Tue, Dec 29, 2009 at 04:28:52PM +0100, Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.31 and 2.6.32.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.31 and 2.6.32. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14894
> Subject : pohmelfs: NULL pointer dereference
> Submitter : Alexander Beregalov <a.beregalov@gmail.com>
> Date : 2009-12-02 1:11 (28 days old)
> References : http://marc.info/?l=linux-kernel&m=125971633107940&w=4
> Handled-By : Evgeniy Polyakov <zbr@ioremap.net>

Yes, I saw this regression and there is a patch to handle this, but it
kind of disables sync at all. Jens Axboe, who introduced per-bdi
writeback patches, did not yet reply.

--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 4 ==
Date: Tues, Dec 29 2009 9:40 am
From: OGAWA Hirofumi

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.31 and 2.6.32.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.31 and 2.6.32. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14889
> Subject : System wakeup by time not working anymore
> Submitter : Malte Schröder <maltesch@gmx.de>
> Date : 2009-12-03 18:06 (27 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=abd6633c67925f90775bb74755f9c547e30f1f20
> References : http://marc.info/?l=linux-kernel&m=125986362631900&w=4

Specified commit would break the pnp driver which is using
driver->shutdown.

Could you test this (untested) patch?
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

[PATCH] rtc_cmos: convert shutdown to new pnp_driver->shutdown

commit abd6633c67925f90775bb74755f9c547e30f1f20 adds shutdown method
to bus driver blindly. With it, driver->shutdown is invalid anymore.

Use pnp_driver->shutdown instead.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

drivers/rtc/rtc-cmos.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)

diff -puN drivers/rtc/rtc-cmos.c~rtc-cmos-shutdown-fix drivers/rtc/rtc-cmos.c
--- linux-2.6/drivers/rtc/rtc-cmos.c~rtc-cmos-shutdown-fix 2009-12-30 01:25:10.000000000 +0900
+++ linux-2.6-hirofumi/drivers/rtc/rtc-cmos.c 2009-12-30 01:27:36.000000000 +0900
@@ -1096,9 +1096,9 @@ static int cmos_pnp_resume(struct pnp_de
#define cmos_pnp_resume NULL