Domain transition functions for TOMOYO Linux.
Every process belongs to a domain in TOMOYO Linux.
Domain transition occurs when execve(2) is called
and the domain is expressed as 'process invocation history',
such as 'kernel /sbin/init /etc/init.d/rc'.
Domain information is stored in
This patch makes access logs sent to auditing subsystem.
TOMOYO Linux uses two channels for auditing.
One is 'AUDIT_TMY_GRANTED', used for auditing accesses which are
granted in the TOMOYO Linux policy.
The other is 'AUDIT_TMY_REJECTED', used for auditing accesses which
are not granted in the
File access control functions for TOMOYO Linux.
TOMOYO Linux checks permission in
open/creat/unlink/truncate/ftruncate/mknod/mkdir/
rmdir/symlink/link/rename/uselib/sysctl .
Each permission can be automatically accumulated into
the policy of each domain using 'learning mode'.
Signed-off-by:
argv[0] check functions for TOMOYO Linux.
If the executed program name and argv[0] is different,
TOMOYO Linux checks permission.
Each permission can be automatically accumulated into
the policy of each domain using 'learning mode'.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by:
Network access control functions for TOMOYO Linux.
TOMOYO Linux checks permission by the following four parameters.
* protocol type (TCP, UDP, RAW)
* access type (bind, listen, connect, accept)
* IP address (Both IPv4 and IPv6 are available)
* port number
In order to check 'TCP accept' and
Mount access control functions for TOMOYO Linux.
TOMOYO Linux checks permission according to
device name, mount point, filesystem type and optional flags.
TOMOYO Linux also checks permission in umount and pivot_root.
Each permission can be automatically accumulated into
the policy using 'learning
Signal control functions for TOMOYO Linux.
TOMOYO Linux checks sending signal by signal number and
the domain of target process. In order to check signal
permission, LSM expansion patch [TOMOYO 14/15] is needed.
Each permission can be automatically accumulated into
the policy of each domain using
LSM wrapper functions for TOMOYO Linux access control.
If bind mounts are used, TOMOYO requires all permissions for
all possible pathnames (whereas AppArmor requires one of possible pathnames).
If struct vfsmount is passed to LSM hooks as AppArmor proposes,
this file will become more simpler and
LSM expansion for TOMOYO Linux.
LSM hooks for sending signal:
* task_kill_unlocked is added in sys_kill
* task_tkill_unlocked is added in sys_tkill
* task_tgkill_unlocked is added in sys_tgkill
LSM hooks for network accept and recv:
* socket_post_accept is modified to return int.
*
On 2007/08/27 21:11, Kyle Moffett wrote:
This is probably not acceptable; I doubt there's a chance in hell
that TOMOYO will get merged as long as it has text-based-language
parsing in the kernel. You also have $NEW_RANDOM_ABUSE_OF_PROCFS and
$PATH_BASED_LSM_ISSUES. See the long flamewars on
* Christoph Hellwig [EMAIL PROTECTED] [2007-10-02 10:14]:
On Sun, Sep 30, 2007 at 01:16:18AM -0700, Andrew Morton wrote:
reviewed the August thread from your version 1 submission and the message I
take away is that the code has been well-received and looks good when
considered on its own
It seems that patches 1-3 are missing.
I'd also suggest making all of the patches a reply to the first email, so
they can be threaded.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a message to
It seems that patches 1-3 are missing.
I'd also suggest making all of the patches a reply to the first email, so
they can be threaded.
Thanks a lot for your suggestions.
Actually we did just as you wrote, but somehow 0-3 parts are missing.
Unfortunately, the parent message [00/15] is in
On Tue, 2 Oct 2007, Kentaro Takeda wrote:
+
+ mb(); /* Instead of using spinlock. */
+ ptr = domain_initializer_list;
+ if (ptr) {
+ while (ptr-next)
+ ptr = ptr-next;
+ ptr-next = new_entry;
+ } else
+
Hello.
Thank you for your comment.
James Morris wrote:
Why do you need to avoid spinlocks for these manipulations?
I don't need to use spinlocks here.
What I need to do here is avoid read/write reordering,
so mb() will be appropriate here.
struct something {
struct something *next;
void
On Tue, 2 Oct 2007, Kentaro Takeda wrote:
LSM expansion for TOMOYO Linux.
LSM hooks for sending signal:
* task_kill_unlocked is added in sys_kill
* task_tkill_unlocked is added in sys_tkill
* task_tgkill_unlocked is added in sys_tgkill
Why do you need racy unlocked versions, in
In article [EMAIL PROTECTED] (at Tue, 2 Oct 2007 21:44:57 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
If I use struct hlist_node which has two pointers,
it needs more memory than struct something which has one pointer.
It is possible to use API defined in include/linux/list.h ,
but to
On Tue, 2 Oct 2007, Tetsuo Handa wrote:
Hello.
Thank you for your comment.
James Morris wrote:
Why do you need to avoid spinlocks for these manipulations?
I don't need to use spinlocks here.
What I need to do here is avoid read/write reordering,
so mb() will be appropriate here.
Hello.
James Morris wrote:
Why do you need racy unlocked versions, in addition to the existing
security_task_kill() hook which is called safely via
check_kill_permission() ?
TOMOYO Linux provides delayed enforcing mode which allows administrator
judge interactively for requests that
Data structures and prototype defitions for TOMOYO Linux.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/include/realpath.h | 44 +++
security/tomoyo/include/tomoyo.h | 517 +
2 files
Basic functions to get canonicalized absolute pathnames
for TOMOYO Linux. Even the requested pathname is symlink()ed
or chroot()ed, TOMOYO Linux uses the original pathname.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
On Tue, 2 Oct 2007, Bill Davidsen wrote:
And yet you can make the exact same case for schedulers as security, you can
quantify the behavior, but if your only choice is A it doesn't help to know
that B is better.
You snipped a key part of the argument. Namely:
Another difference is that
Hello.
Thank you for your comment.
James Morris wrote:
I'm guessing you need this to determine the receiving process, rather than
the socket (which is available via security_sock_rcv_skb()).
Use of security_sock_rcv_skb() was discussed at
http://lkml.org/lkml/2007/8/28/74 ,
and answer is at
On Tue, 02 Oct 2007 17:02:13 -0400
Bill Davidsen [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
On Mon, 1 Oct 2007, Stephen Smalley wrote:
You argued against pluggable schedulers, right? Why is security
different?
Schedulers can be objectively tested. There's this thing called
On Wed, 3 Oct 2007, Alan Cox wrote:
Smack seems a perfectly good simple LSM module, its clean, its based upon
credible security models and sound theory (unlike AppArmor).
The problem with SELinux isn't the theory. It's the practice.
IOW, it's too hard to use.
Apparently Ubuntu is giving
On Tue, 2 Oct 2007, Bill Davidsen wrote:
Unfortunately not so, I've been looking at schedulers since MULTICS, and
desktops since the 70s (MP/M), and networked servers since I was the ARPAnet
technical administrator at GE's Corporate RD Center. And on desktops response
is (and should be
On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote:
From: Casey Schaufler [EMAIL PROTECTED]
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
Linus Torvalds wrote:
Security, on the other hand, very much does depend on the circumstances
and the wishes of the users (or policy-makers). And if we had one module
that everybody would be happy with, I'd not make it pluggable either. But
as it is, we _know_ that's not the case.
And
28 matches
Mail list logo
