linux-kernel - Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part 3/4: introduce new capabilities

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]

Message-Id: <1157905393.23085.5.camel@localhost.localdomain>
Date:	Sun, 10 Sep 2006 17:23:13 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	David Madore <david.madore@....fr>
Cc:	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>,
	LSM mailing-list <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part
	3/4: introduce new capabilities

Ar Sul, 2006-09-10 am 15:42 +0200, ysgrifennodd David Madore:
> Introduce six new "regular" (=on-by-default) capabilities:
> 
>  * CAP_REG_FORK, CAP_REG_OPEN, CAP_REG_EXEC allow access to the
>    fork(), open() and exec() syscalls,

CAP_REG_EXEC seems meaningless, I can do the same with mmap by hand for
most types of binary execution except setuid (which is separate it
seems)

Given the capability model is accepted as inferior to things like
SELinux policies why do we actually want to fix this anyway. It's
unfortunate we can't discard the existing capabilities model (which has
flaws) as well really.

Alan

-
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/