ok, yes, I agree. Root should be allowed general access and we are not
doing this. check_user_group() has a blatant error in the if statement
and attach_shared_memory() does just the opposite of what
check_user_group wants to do. Very conflicting.
I tested your patch as root and a non-root user and all seem ok. I have
merged it.

Thanks!

regards,
Joy

On Tue, 2014-12-02 at 11:12 +0100, Harald Freudenberger wrote:
> On Mon, 2014-12-01 at 13:55 -0600, Joy M. Latten wrote:
> > Hi Harald,
> > 
> > Root has always been required to be part of the pkcs11 group.
> > In  versions prior to 3.0, the pkcs11_startup script did this
> > automatically, so the requirement was not readily exposed to users.
> > In version 3, pkcs11_startup was removed, exposing requirement to users.
> > 
> > http://sourceforge.net/p/opencryptoki/bugs/114/ was opened a while back
> > to track and improve root access. A more complete solution would perhaps
> > drop root permissions on startup and only acquire those permissions when
> > needed. Unfortunately, I just have not had time to do this.
> > 
> > regards,
> > Joy
> > 
> > On Wed, 2014-11-26 at 15:27 +0100, Harald Freudenberger wrote:
> > > Here is a patch to be discussed...
> > > 
> > > Currently even root needs to be member of the pkcs11 group to
> > > successfully execute eg. pkcsconf -t. It is unclear to me,
> > > if this is really the expected behavior. There is some code
> > > and comments in usr/lib/pkcs11/common/new_host.c check_user_and_group()
> > > telling me that uid == 0 or euid == 0 should be allowed without any
> > > group checking. On the other hand before attaching to shared memory in
> > > usr/lib/pkcs11/api/shrd_mem.c.in there is code regardless of any uid
> > > checking for the membership to the pkcs11 group.
> > > 
> > > RHEL uses an own developed patch to disable group checking for user root
> > > and applies this to ock since 2.4.
> > > 
> > > So here is a patch which disables checking of the pkcs11 group
> > > membership for root or euid 0. I leave it to the maintainer of
> > > opencryptoki to apply or reject it ... however the intented behavior
> > > should be documented somewhere.
> > > 
> > > regards, Harald Freudenberger
> > > ------------------------------------------------------------------------------
> > > ...
> > 
> 
> Hi Joy, ... it is still not clear to me what is your position in the
> question if root may be allowed to run all the ock commands without
> the need to be member of the pkcs11 group or not. The bug you are
> pointing to tells me even more: disallow all ock commands initiated by
> root. On the other side there are two locations in the current ock code
> telling two different views: the shrd_mem.c code currently checks if the
> calling user is a member of the pkcs11 group without leaving out any uid
> 0 or euid 0. On the other hand the code in new_host.c explicitly tells
> to skip the test if uid == 0 or euid == 0 (also there seems to be a bug
> in the if statement there). So at least we should know whats the right
> behavior - maybe documented somewhere in a manpage, readme or similar.
> 
> Please note that Redhat has developed a patch for ock 2.4 (and higher)
> which explicitly patches the ock code to remove the pkcs11 group check
> with the intended purpose to let root do everything without beeing
> member of the pkcs11 group.
> 
> However, the right behavior should be documented and both locations
> where checking is done should act the same.
> 
> regards, H.Freudenberger
> 
> 



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opencryptoki-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech

Reply via email to