linux-kernel - Re: capabilities patch: trying a more "consensual" approach

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 16 Sep 2006 00:52:13 +0200
From:	David Madore <david.madore@....fr>
To:	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>,
	LSM mailing-list <linux-security-module@...r.kernel.org>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>
Subject: Re: capabilities patch: trying a more "consensual" approach

Hi, Linux and LSM experts,

I would like to request some advice on how best to create an LSM for
creating underprivileged processes in a way that will seem acceptable
also to those Linux users and kernel hackers who don't want to hear
about it (i.e., my patch should not mess more than necessary with the
rest of the kernel).

In a nutshell, the goal is to do this: when the module is loaded, each
task should have a "cuppabilities" variable, which is initially blank
and, when certain bits are added to it (or removed, depending on your
point of view), prevents certain system calls from succeeding.  This
variable should be inherited across fork() and exec(), and some
interface should be provided to add more cuppabilities (i.e., make a
process less-than-normally privileged).

Now, if I understand correctly, the various alloc_security() LSM hooks
do not stack well: if I want my module to be stackable after SElinux
(and I do), I can't hook task_alloc_security() to create my variable,
so I need to store these "cuppabilities" in a globally visible task
field.  Do I understand correctly?  How acceptable is this?  (We can
assume that 32 bits will be wide enough, so I'm not talking about
adding huge amounts of data to the task struct.)

Second, what would be the cleanest and most acceptable way to provide
an interface to these new "cuppabilities"?  For example, should I add
a new, dedicated, system call?  If so, should I provide new hooks to
it in struct security_operations?  Or is, perhaps, prctl() a better
path (then I would have to request a hook on that in SElinux)?  How
can I best avoid breaking causing any disruption to the rest of the
kernel?

Any advice is welcome.

Happy hacking,

-- 
     David A. Madore
    (david.madore@....fr,
     http://www.madore.org/~david/ )
-
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/