Tony Jones wrote:
The following are a set of patches the goal of which is to pass vfsmounts
through select portions of the VFS layer sufficient to be visible to the LSM
inode operation hooks.
I was looking forward to these patches for so long.
Chris Wright wrote:
This kind of change (or
Hello.
Hao Xu wrote:
If the purpose of the LSM framework is not just satisfying selinux, then
I also want LSM framework add some hooks.
The problems are at accept() and recvmsg() operation.
I want to return error on security_socket_post_accept().
I want a new hook security_socket_post_recvmsg()
Hello.
Casey Schaufler wrote:
Putting access control on ports rather than sockets is a novel
approach. It is a lot simpler underneath and more consistant with
the way other object name spaces are treated.
I prefer Novell's approach. It is easy like using iptables.
In TOMOYO Linux, I do in the
Hello.
Casey Schaufler wrote:
Sorry, but I don't understand your objection. If AppArmor is configured
to allow everyone access to /bin/gzip but only some people access to
/bin/gunzip and (important detail) the single binary uses argv[0]
as documented and (another important detail) there
Hello.
I forgot to say another example.
This would be unlikely situation to assume /usr/bin/passwd (a program that has
to be setuid root)
and /bin/cat (a program that needn't to be setuid root) are the hardlinks of
busybox.
An administrator defines profile for /usr/bin/passwd that allows
read
Hello.
Kyle Moffett wrote:
secure fashion. It sounds like TOMOYO Linux would not be able to
handle this situation at all; I would either have to completely turn
off that security feature and lose most of the functionality of
TOMOYO Linux, or hard-code the list of realms into the
Hello.
Kyle Moffett wrote:
Part of the reason that Fedora has a large quantity of that
restorecon and restorecond crap is that there is a certain amount of
broken binary software needing executable stack/heap (such as
flashplayer), programs without comprehensive or complete policies,
Hello.
Crispin Cowan wrote:
AppArmor actually does something similar to this, by mediating all of
the ways that you can make an alias to a file. These are:
* Symbolic links: these actually don't work for making aliases with
respect to LSM-based security systems such as AppArmor,
Hello.
Andreas Gruenbacher wrote:
But, from the pathname-based access control's point of view,
bind mount interferes severely with pathname-based access control
because it is impossible to determine which pathname was requested.
Wrong. It is very well possible to determine the path of a
Hello.
David Lang wrote:
as I understand it SELinux puts one label on each file, so if you have
three files accessed by two programs such that
program A accesses files X Y
program B accesses files Y Z
then files X Y and Z all need separate labels with the policy stateing
that program A
Hello.
James Morris wrote:
Note that while SELinux does also have a similar capability with the
audit2allow tool, it should be considered an expert tool, the output of
which needs to be understood before use (as noted in its man page).
Yes, adding allow statement without understanding what
Hello.
I just now made demo movies how TOMOYO Linux looks like.
http://tomoyo.sourceforge.jp/data/CentOS5-install.avi is
a movie that demonstrates how to install TOMOYO Linux 1.4.1 on CentOS 5.
http://tomoyo.sourceforge.jp/data/CentOS5-learning.avi is
a movie that demonstrates how the TOMOYO
Thank you for your suggestion.
Paul Moore wrote:
I believe the existing security_inet_conn_request() LSM hook should allow you
to do what you want. Adding another hook _after_ the inbound connection has
been accepted is probably a bad idea.
Unfortunately, security_inet_conn_request() doesn't
Hello.
Paul Moore wrote:
Perhaps you could move the security_post_accept() hook further up and add a
return value? I do not see any current in-tree users of the hook and I
imagine moving it up would actually make the existing hook a bit more useful
in general.
If there are no objections,
Hello.
Paul Moore wrote:
Thinking about your problem (personal firewall) a bit more I can't help but
wonder if your solution would be better implemented as a netfilter module?
If netfilter hooks allow blocking operation, it may be a solution.
But making decisions at
?
Regards.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
include/linux/security.h | 38 ++
net/socket.c | 40 ++--
security/dummy.c | 11 +--
3 files changed, 77 insertions(+), 12 deletions
?
Regards.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
include/linux/security.h | 38 ++
net/socket.c | 40 ++--
security/dummy.c | 11 +--
3 files changed, 77 insertions(+), 12 deletions
Hello.
Thank you for your comment.
David Miller wrote:
I don't think it's such a hot idea to return errors if the
wait_on_sync_kiocb() has returned success.
My patch may return errors for non-wait_on_sync_kiocb() case too.
Are you saying only wait_on_sync_kiocb() case is bad?
If so, could you
Thank you for your comment.
I have a question regarding netfilter infrastructure.
I want to filter messages using task_struct-security.
Can the netfilter's queuing to userspace feature
get a list of struct task_struct who shares a socket
that is going to receive incoming messages?
My approach
Hello.
Paul Moore wrote:
* post_recv_datagram is added in skb_recv_datagram.
Can you explain to me why this is not possible using the existing
security_socket_sock_rcv_skb() LSM hook?
socket_sock_rcv_skb() is a hook for enqueue time.
I want a hook for dequeue time, because what TOMOYO
Hello.
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 AppArmor for
Hello.
Paul Moore wrote:
I apologize for not recognizing your approach from our earlier discussion on
the LSM mailing list in July. Unfortunately, I have the same objections to
these changes that I did back then and from what I can recall of the
discussion the rest of the kernel
Hello.
Thank you for your comment.
Hmm, I can't understand why I have to perform access control at enqueue time.
What I want to do is
allow process1 receive UDP packets from 10.0.0.1 port 1024
allow process2 receive UDP packets from 10.0.0.2 port 2048
when there is no guarantee that
Hello.
Thank you very much for your time, Paul.
Yes, you understood what I wanted to do.
TOMOYO Linux's approach:
(1) It uses userspace intervention to allow/reject
connections and/or packets based on the application's domain.
Since existent hooks can't be used for this purpose,
I
Hello.
MAC can prevent execution of programs that are not
permitted by security policy.
Some exploits sends shellcodes containing execve(/bin/sh) like
while (1) {
update_condition();
if (condition_is_met) execve(/bin/sh);
};
and the victim server process executes
while (1) {
Hello.
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 AppArmor
Hello.
Kyle Moffett wrote:
Yes, that's what securityfs is there for. Be mindful, though, that
Thank you, I see.
adding a text-based-language parser into securityfs is just as
unacceptable as adding a text-based-language parser to procfs.
Now, let me ask for some hints
regarding
Hello.
Casey Schaufler wrote:
There is work required to audit, SELinux, and LSM that will be
required before Smack or any other module can really use audit
properly. Smack using audit would be nice, but there are already
interesting cases that don't require it. I have fixing up audit
on my
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
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
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
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later, ptr-next is assigned non-NULL address.
(3) Assigning to ptr-next is done atomically.
(4) wmb after asigning
Hello.
KaiGai Kohei wrote:
If so, you can apply RCU instead to avoid read lock
when scanning the list, like:
rcu_read_lock();
list_for_each_entry(...) {
}
rcu_read_unlock();
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock() makes
Hello.
YOSHIFUJI Hideaki wrote:
It is not a good practice. Please free such objects.
BTW, how many objects do you have in the list?
It varies from 0 to some thousands,
depending on the policy supplied by the administrator and/or the policy
appended by learning mode.
Peter Zijlstra wrote:
About use of singly-linked list:
What my SLL (singly-linked list) holds is bit different from other lists.
Almost all lists hold list of elements (e.g. buffer) that are used
*temporarily*.
Thus, adding to the list and removing from the list are essential.
My SLL holds ACL (access control
Hello.
Peter Zijlstra wrote:
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock() makes in_atomic() true, so I think I can't
sleep.
You can indeed not sleep in an rcu_read_lock() section. However, you
could grab a reference on an item, stop the
Hello.
Jun WANG wrote:
I'm sorry,I think I got your idea, if you do not need ptr in
my_task_that_may_sleep(), why you need to grab a reference to ptr. If
your my_task_that_may_sleep() needs ptr, and according to the
memory region pointed by ptr never be removed. you say,
it is ok to use ptr
Hello.
Peter Zijlstra wrote:
So, I don't need to grab a reference to ptr
because memory region pointed by ptr will never be kfree()ed.
And it is legal to use ptr after rcu_read_unlock()
because memory region pointed by ptr will never be kfree()ed.
Still think that is a very BAD (tm)
TOMOYO Linux is our work in the field of security enhanced Linux.
This is the fourth submission of TOMOYO Linux
( http://lkml.org/lkml/2007/10/2/170 ).
Thank you very much for feedbacks on previous submission.
We followed the following comments and now submitting again.
* Replace struct
TOMOYO Linux uses pathnames for auditing and controlling file access.
Therefore, namespace_sem is needed.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/namespace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig
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 | 43 +++
security/tomoyo/include/tomoyo.h | 513 +
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]
---
security/tomoyo
-security.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/domain.c | 1259 +++
1 file changed, 1259 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6/security
' are not checked.
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: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/net.c | 963 ++
1
mode'.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/mount.c | 1010
1 file changed, 1010 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6/security
Hello.
Peter Zijlstra wrote:
append_function() {
down(semaphore_for_write_protect);
...
ptr = head;
while (ptr-next) ptr = ptr-next;
ptr-next = new_entry;
...
up(semaphore_for_write_protect);
}
If at all possible, use struct mutex.
Fixed in the fourth
Hello.
James Morris wrote:
It seems that standard kernel list API does not have singly-linked list
manipulation.
I'm considering the following list manipulation API.
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
OK. I
Hi.
You know, you really are supposed to understand the code you are modifying...
Quiz: what are those vfsmounts and how are they related?
These two vfsmounts should be same since the kernel doesn't support
rename or link operations that accrosses mount points.
So, we don't have to pass both
Hello.
Simon Arlott wrote:
I currently have an LSM that only handles permissions for socket_bind
and socket_listen, I load it and then capability as secondary on
boot - but now I can't because the LSM framework is now just the LS
framework.
I think there are two other problems regarding LSM.
Hello.
Adrian Bunk wrote:
You have a \? pattern which is defined as 1 byte character other
than '/'.
Don't worry. The \? pattern is for temporary files with /tmp/prefixXX
pattern.
/tmp/prefixXX is represented as /tmp/prefix\?\?\?\?\?\? in TOMOYO Linux's
syntax.
The user usually
Hello.
Adrian Bunk wrote:
And \* is not a replacement for \?. It's quite common to have both ways
to express one character and to express at least one character, and
both have their use cases and will get used if available.
You can use \? to represent one character and
\?\* to represent at
Hello.
Christoph Hellwig wrote:
Isn't security_inode_create() a part of VFS internals?
It's not. security_inode_create is part of the LSM infrastructure, and
the actual methods are part of security modules and definitively not
VFS internals.
The reason why I want to access namespace_sem
Hello.
Christoph Hellwig wrote:
Same argument as with the AA folks: it does not have any business looking
at the vfsmount. If you create a file it can and in many setups will
show up in multiple vfsmounts, so making decisions based on the particular
one this creat happens through is wrong
Hello.
Trond Myklebust wrote:
This patch allows LSM hooks refer previously associated struct vfsmount
parameter
so that they can calculate pathname of given struct dentry.
NACK to this. Passing function parameters through the task_struct is
definitely not an acceptable hack (unless
YOSHIFUJI Hideaki wrote:
I think you can use in6_pton() here.
in4_pton().
I see. I'll try it later.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hello.
Thank you for your feedback.
Paul Moore wrote:
With this patch the 'cpu_flags' variable will be used in two different
if-blocks in this function and declared locally within each block. Please
move the 'cpu_flags' declaration to the top of the function so it only needs
to be
Hello.
Trond Myklebust wrote:
The problem is that you have thrown away the main tool for documenting
the requirement, and for enforcing correctness (i.e. function argument
checking by the compiler).
I'm sorry. I wanted to know whether the below approach is possible.
The old functions are
Hello.
Trond Myklebust wrote:
I'm confused. How do you tell the difference between a 'userland'
request and a 'kernel' request, and why is the latter safe from a
security perspective?
For example, if userland process wants to create a directory,
it will call mkdir(2).
In the kernel, mkdir(2)
]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
include/linux/security.h | 74 +++
kernel/signal.c | 17 ++
net/core/datagram.c | 29 --
net/socket.c |7 +++-
security/dummy.c | 32
Hello.
Christoph Hellwig wrote:
NACK to this. Passing function parameters through the task_struct is
definitely not an acceptable hack
Exactly. Having a vfsmount other than the current processes root or
current working directory in task_struct doesn't make any sense.
The process's root and
Hello.
Paul Moore wrote:
If that is the case then the second call to
skb_peek() will return a different skb then the one you passed to
security_post_recv_datagram().
Yes. The second call to skb_peek() might return a different skb than the one
I passed to security_post_recv_datagram().
this datagram
will repeat recvmsg() forever, which is a worse side effect.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
include/linux/security.h | 34 +-
net/core/datagram.c | 26 --
net
Hello.
Andrew Blaich wrote:
I have been unsuccessful in using dentry and vfsmnt from the current
task_struct via the d_path() lookup function.
Can't you get it from current-mm-mmap?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/common.c#L745
Try d_path() instead of
Hello.
Andrew Blaich wrote:
Here's a question, why is there this round about way of retrieving the
path of the task? Wouldn't it be slightly more efficient to store it
explicitly as character array within the task_struct ?
I don't know the reason. But I guess that
(1) Printing the pathname
Hello, Samir.
Did you receive the following messages?
Since these messages were dropped at vger.kernel.org ,
I'm worrying that you couldn't receive the following messages.
Tetsuo Handa wrote:
Hello.
Samir Bellabes wrote:
what differences between you approach and netfilter in this case
Hello.
Thank you for feedback.
Serge E. Hallyn wrote:
TOMOYO Linux is a DIY tool for understanding and protecting your system.
TOMOYO Linux policy definitions are absolutely readable to Linux users, and
TOMOYO Linux supports unique policy learning mechanism which automatically
Are they
Hello.
Serge E. Hallyn wrote:
* namespace manipulation. (i.e. mount()/umount()/pivot_root())
do you track mounts namespace cloning?
Yes. TOMOYO can recognize mount operation with the following flags.
--bind --move --remount
--make-unbindable --make-private
Hello.
This is a repost of a patch submitted at http://lkml.org/lkml/2007/11/19/545 .
Current status is that I'm waiting for Samir Bellabes's answer
whether we can handle the following example without this patch.
Tetsuo Handa wrote:
Hello.
Samir Bellabes wrote:
what differences between
Hello.
Christoph Hellwig wrote:
Just FYI: A NACK to such an addition doesn't simply go away by
ignoring it.
Excuse me. What NACK is remaining?
About the below comments?
NACK to this. Passing function parameters through the task_struct is
definitely not an acceptable hack
Exactly.
Hello.
Greg KH wrote:
If sysfs becomes not available at /sys/ , where securityfs is going to be
mounted?
sysfs is not going away any time soon, don't worry :)
I see. Thanks.
-
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a message to
to control
after the recipient of the incoming packet is known.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
include/linux/security.h | 34 +-
net/core/datagram.c | 29 -
net
Hello.
Al Viro wrote:
On Fri, Jan 25, 2008 at 07:20:56PM +0900, Kentaro Takeda wrote:
In the LSM ml, we are discussing about
how to know requested pathnames within LSM modules.
Currently, VFS helper functions don't pass struct vfsmount parameter.
Therefore, we cannot calculate
that conventional permission checks are done twice
because I want to do DAC checks before MAC checks.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/namei.c | 176 ++-
fs/open.c| 11 ++
include/linux/fs.h |1
Hello.
No printable comments, except for that:
(e) why don't you guys move the Linus' Serious Mistake to _callers_ of
vfs_mknod() and its ilk?
Which obviously solves all problems with having vfsmount.
Excuse me. I didn't understand what the Linus' Serious Mistake to
_callers_ of
75 matches
Mail list logo
