linux-kernel - Re: [PATCH 13/22] 2.6.22-rc3 perfmon2 : common core functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070604115648.GB8614@frankl.hpl.hp.com>
Date:	Mon, 4 Jun 2007 04:56:48 -0700
From:	Stephane Eranian <eranian@....hp.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Stephane Eranian <eranian@....hp.com>,
	perfmon@...ali.hpl.hp.com
Subject: Re: [PATCH 13/22] 2.6.22-rc3 perfmon2 : common core functions

Andi,

On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote:
> > +   * pmu_desc: subdir containing the PMU register mapping information
> > +
> > +   * reset_stats(W): echo 0 > reset_stats resets the statistics collected by perfmon2.
> > +   		stats are available per-cpu in /sys/devices/system/cpu/cpu*/perfmon
> > +   	
> > +   * smpl_buffer_mem_cur(RO): reports the amount of memory currently dedicated to sampling
> > +   		buffers by the kernel.
> > +
> > +   * smpl_buffer_mem_max(RW): maximum amount of memory usable for sampling buffers.
> > +   		-1 means all that is available.
> 
> -1 seems dangerous. 
> 
> > +
> > +   * sys_group(RW): which users group is allowed to create a system-wide contexts.
> > +   		-1 means any group
> 
> Wouldn't this better be a capability bit? Then it could be just set
> in the normal pam configuration files.
> 
> > +
> > +   * sys_sessions_count(RO): number of loaded system-wide contexts
> > +
> > +   * task_group(RW): which users group is allowed to create per-thread contexts.
> > +   		-1 means any group
> 

I spent quite some time looking at the kernel code for capabilities and also how to
control them from userland. I agree with you that it would be nicer to use capabilities
to control which users can create system-wide or per-thread perfmon sessions. We could
simply create two new capabilities: CAP_PERFMON_SYS and CAP_PERFMON_THREAD. Then,
I can envision a setup where a sysadmin would grant the capabilities to users when they login
via PAM.

There are two problems with this at the moment:

	- the 32bit for capabilities have been exhausted (kernel_cap_t is u32). We would
	  need to increase to u64. That would impact __user_cap_data_struct which is used
	  by the captset()/capget() syscalls.

	- I have not been able to find how one could grant/deny capabilities via PAM and
	  especially for login. Libcap does not seem to be used. There was a pam_cap at
	  some point, it seems abandonned by now.  I am not a linux security
	  expert, so there may be newer ways of setting capabilities for processes.

Any comments?

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