Re: Linux Firmware Signing

[Joshua Brindle]

Roberts, William C wrote:

From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
security-mod...@vger.kernel.org] On Behalf Of Joshua Brindle
Sent: Tuesday, September 1, 2015 7:13 AM
To: Paul Moore
Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
seli...@tycho.nsa.gov; Schaufler, Casey; Stephen Smalley; Matthew Garrett;
Kees Cook; Vojtech Pavlík; Seth Forshee; james.l.mor...@oracle.com; Dmitry
Kasatkin; Johannes Berg; Joey Lee; Kyle McMartin; linux-
wirel...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Lutomirski; linux-
security-mod...@vger.kernel.org; Greg Kroah-Hartman; Vitaly Kuznetsov; David
Woodhouse
Subject: Re: Linux Firmware Signing

Paul Moore wrote:


Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.


Yes I would say this is low on my end. Especially if we can kill off
Reloadable policy support on Android, my need for this goes away 100%.



I'm not sure who "we" is as you are the only person I've heard 
advocating for removing that support.



The fact that there are so many userspace specific parts of the policy that 
never
make it into the kernel precludes any meaningful verification anyway.


Yes and no. On Android, if I was able to load a policy I could grant myself 
capabilities that
We're not possible via the userspace portions, i.e. relabeling, etc. Granted, 
not checking the
userspace portions Is not great. In an ideal world, everything is checked. 
However, the main
reason to doing it in the kernel is where you want your trust to be. For 
instance, If I trust that
userspace Loader, then I need to trust that + the kernel. In the case of 
verifying the policy signature
In the kernel, I need to trust only the kernel.


Especially on Android, userspace files are very important. Changing 
seapp_contexts or property_contexts can easily get you a privilege 
escalation to let you do whatever. Checking only the kernel binary is a 
half-solution and should not even be considered.




As far as the desktop environment, I claim ignorance and have no input there.


And SELinux already has a mechanism for raising the integrity of a process to do
things like signature checking in userspace, the domain transition. If someone
wants validation of the SELinux policy they just need to eliminate every domains
ability to load policy except for a trusted policy loader that does signature
checking.
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Joshua Brindle]

Paul Moore wrote:



Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.



The fact that there are so many userspace specific parts of the policy 
that never make it into the kernel precludes any meaningful verification 
anyway.


And SELinux already has a mechanism for raising the integrity of a 
process to do things like signature checking in userspace, the domain 
transition. If someone wants validation of the SELinux policy they just 
need to eliminate every domains ability to load policy except for a 
trusted policy loader that does signature checking.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Create new NetFilter table

[Joshua Brindle]

Victor Porton wrote:

I propose to create a new NetFilter table dedicated to rules created 
programmatically (not by explicit admin's iptables command).

Otherwise an admin could be tempted to say `iptables -F security` which would 
probably break rules created for example by sandboxing software (which may 
follow same-origin policy to restrict one particular program to certain domain 
and port only). Note that in this case `iptables -F security` is a security 
risk (sandbox breaking)?

New table could be possibly be called:

- temp
- temporary
- auto
- automatic
- volatile
- daemon
- system
- sys

In iptables docs it should be said that this table should not be manipulated 
manually.


Is it possible that the solution to your sandboxing problem is seccomp 
filter?


http://outflux.net/teach-seccomp/

You'd filter out any syscall that can make outbound connections and then 
only pass already opened sockets to the sandboxed threads?


seccomp filter was actually created for sandboxing, so that user 
applications could voluntarily shed the ability to call certain syscalls 
before handling untrusted data.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] selinux: make mls_compute_sid always polyinstantiate

[Joshua Brindle]

Eamon Walsh wrote:
This patch removes the requirement that the new and related object 
types differ in order to polyinstantiate by MLS level.  This allows 
MLS polyinstantiation to occur in the absence of explicit type_member 
rules or when the type has not changed.


Potential users of this support include pam_namespace.so (directory 
polyinstantiation) and the SELinux X support (property 
polyinstantiation).


Signed-off-by: Eamon Walsh <[EMAIL PROTECTED]>
---

mls.c |   11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)


diff --git a/security/selinux/ss/mls.c b/security/selinux/ss/mls.c
index fb5d70a..3bbcb53 100644
--- a/security/selinux/ss/mls.c
+++ b/security/selinux/ss/mls.c
@@ -537,15 +537,8 @@ int mls_compute_sid(struct context *scontext,
/* Use the process effective MLS attributes. */
return mls_context_cpy_low(newcontext, scontext);
case AVTAB_MEMBER:
-/* Only polyinstantiate the MLS attributes if
-   the type is being polyinstantiated */
-if (newcontext->type != tcontext->type) {
-/* Use the process effective MLS attributes. */
-return mls_context_cpy_low(newcontext, scontext);
-} else {
-/* Use the related object MLS attributes. */
-return mls_context_cpy(newcontext, tcontext);
-}
+/* Use the process effective MLS attributes. */
+return mls_context_cpy_low(newcontext, scontext);
default:
return -EINVAL;
}


Should there be a patch to update mls.c in libsepol as well? I hope we 
are keeping the kss and uss in sync.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

[Joshua Brindle]

Kyle Moffett wrote:

On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:

Kyle Moffett wrote:
Actually, a fully-secured strict-mode SELinux system will have no 
unconfined_t processes; none of my test systems have any.  Generally 
"unconfined_t" is used for situations similar to what AppArmor was 
designed for, where the only "interesting" security is that of the 
daemon (which is properly labelled) and one or more of the users are 
unconfined.


Interesting. In a Targeted Policy, you do your policy administration 
from unconfined_t. But how do you administer a Strict Policy machine? 
I can think of 2 ways:


[snip]


* there is some type that is tighter than unconfined_t but none the
  less has sufficient privilege to change policy

To me, this would be semantically equivalent to unconfined_t, because 
any rogue code or user with this type could then fabricate 
unconfined_t and do what they want


Well, in a strict SELinux system, someone who has been permitted the 
"Security Administrator" role (secadm_r) and who has logged in through 
a "login_t" process may modify and reload the policy.  They are also 
permitted to view all files up to their clearance, write files below 
their level, and relabel files.  On the other hand, they do not have 
any system-administration privileges (those are reserve for sysadm_r).




Ofcourse secadm can give himself privileges to anything he wants, that 
isn't necessarily the point though, he is trusted to change the policy. 
He is, however, protected from other people: he can't, for example, read 
user_home_t files. This protects the integrity of his environment and 
the processes he runs. unconfined_t, of course, does not have this 
protection.


Under the default policy the security administrator may disable 
SELinux completely, although that too can be adjusted as "load policy" 
is yet another specialized permission.




load policy is pretty course grained, there are ways to make policy 
modification privileges more fine grained though such as by using the 
policy management server.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Joshua Brindle]

Casey Schaufler wrote:

--- Crispin Cowan <[EMAIL PROTECTED]> wrote:

  

Dr. David Alan Gilbert wrote:
...

Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.

Note that John Johansen is also interested in allowing non-privileged
users to manipulate AppArmor policy, but his view was to only allow a
non-privileged user to further tighten the profile on a program. To me,
that adds complexity with not much value, but if lots of users want it,
then I'm wrong :)



Now this is getting interesting. It looks to me as if you've implemented
a mandatory access control scheme that some people would like to be able
to use as a discretionary access control scheme. This is creepy after
seeing the MCS implementation in SELinux, which is also a DAC scheme
wacked out of a MAC scheme. Very interesting indeed.
  


This is the same sort of thing we are trying to do in SELinux with the 
policy management server 
, 
ofcourse the policy management server enforces SELinux policy on what 
can be changed and what can't. We devised a scheme to allow the policy 
to become more restrictive without being able to change the policy 
'intent' using a type hierarchy.


In fact I was talking to a coworker today about how this could be done 
with smack, using the same kind of hierarchy and allowing unprivileged 
users (eg., those without MAC_OVERRIDE) to create new smack labels 
'under' their own which would be restricted. This is interesting because 
of the ability to create new smack domains on the fly but since only 
privileged users can do it it is of limited use. Imagine if a user could 
create a new domain for their webbrowser or anything else they care to. 
Since they can't add rules to the policy it would effectively just be a 
user sandbox, an interesting use indeed.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NetLabel: Introduce a new kernel configuration API for NetLabel - For 2.6.24-rc-git11 - Smack Version 10

[Joshua Brindle]

Joshua Brindle wrote:

Casey Schaufler wrote:

From: Paul Moore <[EMAIL PROTECTED]>

Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem 
without

relying on assistance from userspace.
  
I'm still not receiving the actual patch email on lsm (perhaps its too 
long and should be split up..) so I'll just respond on this email. 
Using the v10 patches on your website I'm still seeing strange 
behavior where echo foo > /proc/self/attr/current changes the label of 
every process on the system to foo (verified with both ps -AZ and cat 
/proc/1/attr/current).



Actually I'm getting more strange behavior:

On terminal 1 I do:
echo foo > /proc/self/attr/current
then ps -AZ shows foo for every process
touch somefile; attr -S -g SMACK64 somefile says foo

On terminal 2 I do:
ps -AZ and everything shows up as _
cat /proc/$pid of bash on term 1/attr/current is _



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NetLabel: Introduce a new kernel configuration API for NetLabel - For 2.6.24-rc-git11 - Smack Version 10

[Joshua Brindle]

Casey Schaufler wrote:

From: Paul Moore <[EMAIL PROTECTED]>

Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
  
I'm still not receiving the actual patch email on lsm (perhaps its too 
long and should be split up..) so I'll just respond on this email. Using 
the v10 patches on your website I'm still seeing strange behavior where 
echo foo > /proc/self/attr/current changes the label of every process on 
the system to foo (verified with both ps -AZ and cat /proc/1/attr/current).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Joshua Brindle]

Casey Schaufler wrote:

The Smack patch and Paul Moore's netlabel API patch,
together for 2.6.24-rc1. Paul's changes are identical
to the previous posting, but it's been a while so they're
here again.

The sole intent of change has been to address locking
and/or list processing issues. Please don't hesitate to
point out any problems that you might see or suggest
alternatives where things might not be to your liking.

This version is aimed at 2.6.24, and has been tested
against 2.6.24-rc1.
  
with both of these patches applied to 2.6.24-rc1 I get the following 
oops when nfsd starts:


BUG: unable to handle kernel NULL pointer dereference at virtual address 
013c

printing eip: c01d7e39 *pde = 
Oops:  [#1] SMP

Pid: 4094, comm: lockd Not tainted (2.6.24-rc1 #3)
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at smack_socket_post_create+0x46/0xd2
EAX: c19440c0 EBX:  ECX: 0001 EDX: c168ddd8
ESI: 0002 EDI:  EBP: 0006 ESP: c168ddd8
DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
Process lockd (pid: 4094, ti=c168c000 task=c1577ab0 task.ti=c168c000)
Stack: c1464c00 c01d7ac6 c19440e8 c01d4fb4 c016544c c038c660 c19440c0 
0001
  c01d53eb 0006 0001 fff4 c0283374 0006 0001 
0002
  c1944540 c168df34 c1944540 0800 c02833b6 c168df34 c1944540 
c2039d8c

Call Trace:
[] smack_inode_alloc_security+0x14/0x24
[] security_inode_alloc+0x16/0x17
[] alloc_inode+0x118/0x170
[] security_socket_post_create+0x1f/0x23
[] sock_create_lite+0x4d/0x6c
[] kernel_accept+0x23/0x5a
[] svc_tcp_recvfrom+0xf9/0x7e7
[] run_timer_softirq+0x2f/0x154
[] __update_rq_clock+0x19/0x156
[] clocksource_get_next+0x39/0x3f
[] update_wall_time+0x54b/0x6af
[] schedule+0x575/0x58f
[] svc_udp_recvfrom+0x175/0x367
[] __rcu_process_callbacks+0xeb/0x153
[] schedule_timeout+0x13/0x8d
[] svc_sock_release+0xdd/0x149
[] svc_recv+0x2df/0x395
[] apic_timer_interrupt+0x28/0x30
[] default_wake_function+0x0/0x8
[] lockd+0xe3/0x1f3
[] schedule_tail+0x18/0x52
[] ret_from_fork+0x6/0x1c
[] lockd+0x0/0x1f3
[] lockd+0x0/0x1f3
[] kernel_thread_helper+0x7/0x10
===
Code: 38 c0 75 0c 64 a1 00 c0 3d c0 8b 80 c0 04 00 00 e8 31 f5 ff ff 89 
83 64 01 00 00 31 ff 83 fe 02 0f 85 88 00 00 00 8b 5b 14 89 e2 <8b> 83 
3c 01 00 00 c7 04 24 00 00 00 00 c7 44 24 04 00 00 00 00

EIP: [] smack_socket_post_create+0x46/0xd2 SS:ESP 0068:c168ddd8
BUG: unable to handle kernel NULL pointer dereference at virtual address 
013c

printing eip: c01d7e39 *pde = 
Oops:  [#2] SMP

Pid: 4095, comm: nfsd Tainted: G  D (2.6.24-rc1 #3)
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at smack_socket_post_create+0x46/0xd2
EAX: c1944240 EBX:  ECX: 0001 EDX: c1603e00
ESI: 0002 EDI:  EBP: 0006 ESP: c1603e00
DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
Process nfsd (pid: 4095, ti=c1602000 task=c1559ab0 task.ti=c1602000)
Stack: c1464c00 c01d7ac6 c1944268 c01d4fb4 c016544c c038c660 c1944240 
0001
  c01d53eb 0006 0001 fff4 c0283374 0006 0001 
0002
  c19443c0 c1603f5c c19443c0 0800 c02833b6 c1603f5c c19443c0 
c16c9e00

Call Trace:
[] smack_inode_alloc_security+0x14/0x24
[] security_inode_alloc+0x16/0x17
[] alloc_inode+0x118/0x170
[] security_socket_post_create+0x1f/0x23
[] sock_create_lite+0x4d/0x6c
[] kernel_accept+0x23/0x5a
[] svc_tcp_recvfrom+0xf9/0x7e7
[] __wake_up_common+0x32/0x5c
[] _spin_lock_bh+0x8/0x18
[] lock_sock_nested+0x84/0x8c
[] svc_udp_recvfrom+0x175/0x367
[] svc_sock_release+0xdd/0x149
[] svc_recv+0x2df/0x395
[] sched_move_task+0xa0/0xa7
[] default_wake_function+0x0/0x8
[] nfsd+0xcc/0x27b
[] nfsd+0x0/0x27b
[] kernel_thread_helper+0x7/0x10
===
Code: 38 c0 75 0c 64 a1 00 c0 3d c0 8b 80 c0 04 00 00 e8 31 f5 ff ff 89 
83 64 01 00 00 31 ff 83 fe 02 0f 85 88 00 00 00 8b 5b 14 89 e2 <8b> 83 
3c 01 00 00 c7 04 24 00 00 00 00 c7 44 24 04 00 00 00 00

EIP: [] smack_socket_post_create+0x46/0xd2 SS:ESP 0068:c1603e00


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Joshua Brindle]

Casey Schaufler wrote:

The Smack patch and Paul Moore's netlabel API patch,
together for 2.6.24-rc1. Paul's changes are identical
to the previous posting, but it's been a while so they're
here again.

The sole intent of change has been to address locking
and/or list processing issues. Please don't hesitate to
point out any problems that you might see or suggest
alternatives where things might not be to your liking.

This version is aimed at 2.6.24, and has been tested
against 2.6.24-rc1.

Thank you again.


For some reason I didn't get 2/2 so I can't make an inline comment but 
one thing I noticed while trying to build a smack kernel is that smack 
has a kconfig dependancy on NETLABEL and SECURITY_NETWORK. This is 
unfortunate because user X wanting to try out smack won't see it in the 
config until he goes and enables those things (which he wouldn't know 
about without reading the smack Kconfig). It would be nice if those were 
selects instead.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Joshua Brindle]

Andi Kleen wrote:

- hm, netlabels.  Who might be a suitable person to review that code?
  Seems that Paul Moore is the man.  Maybe he'd be interested in taking a
  look over it (please?)



I personally consider these IP options it uses to be pretty useless. Who could 
ever use that without cryptographic authentication? Clearly when they 
were designed in the original IP spec long ago the designers didn't understand
network security very well because the whole field was at its infancy. And 
CIPSO doesn't solve any of these fundamental issues.


It assumes a trusted network which is a very dangerous assumption.  I don't 
think that was in the original patch I looked at, I surely would have 
objected to it.


Perhaps take the network part out? I guess SMACK would be useful
locally even without questionable network support.
  


CIPSO is supported on SELinux as well. It certainly has uses where IPSec 
is excessive. One example is someone I talked to recently that basically 
has a set of blade systems connected with a high speed backplane that 
looks like a network interface. CIPSO is useful in this case because 
they can't afford the overhead of IPSec but need to transfer the level 
of the connection to the other machines. The backplane is a trusted 
network and that isn't a dangerous assumption in this case.


CIPSO also lets systems like SELinux and SMACK talk to other trusted 
systems (eg., trusted solaris) in a way they understand. I don't 
regularly support CIPSO as I believe IPSec labeling is more useful in 
more situations but that doesn't mean CIPSO is never useful.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

[Joshua Brindle]

Kyle Moffett wrote:

On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:

Your boolean solution requires more forthought than the Smack rule 
solution, but I'll give it to you once you've fleshed out your "##" 
lines.


How does it require more forethought?  When I want to turn it on, I 
write and load the 5 line policy then add the cronjobs.  Yours 
involves giving cron unconditional permission to write to your 
security database (always a bad idea) and then adding similar cronjobs.




nit: without the selinux policy server (which is not production ready by 
any means) we have to grant the same to cron in this case (or at least 
to the domain that cron runs the cronjobs in). SELinux and Smack alike 
need special permissions to modify the running policy, no surprises there.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

[EMAIL PROTECTED] wrote:

On Thu, 21 Jun 2007, Joshua Brindle wrote:


Lars Marowsky-Bree wrote:

 On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
 


>  Um, no.  It might not be able to directly open files via that 
path, but
>  showing that it can never read or write your mail is a rather 
different

>  matter.
>
 Yes. Your use case is different than mine.



So.. your use case is what? If an AA user asked you to protect his 
mail from his browser I'm sure you'd truthfully answer "no, we can't 
do that but we can protect the path to your mail from your browser".. 
I think not. One need only look at the wonderful marketing literature 
for AA to see what you are telling people it can do, and your above 
statement isn't consistent with that, sorry.


remember, the policies define a white-list



Except for unconfined processes.

so if a hacker wants to have mozilla access the mail files he needs to 
get some other process on the sysstem to create a link or move a file 
to a path that mozilla does have access to. until that is done there 
is no way for mozilla to access the mail through the filesystem.


other programs could be run that would give mozilla access to the mail 
contents, but it would be through some other path that the policy 
permitted mozilla accessing in the first place.


Or through IPC or the network, that is the point, filesystem only 
coverage doesn't cut it; there is no way to say the browser can't access 
the users mail in AA, and there never will be.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

Lars Marowsky-Bree wrote:

On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:


  

Um, no.  It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.



Yes. Your use case is different than mine.
  


So.. your use case is what? If an AA user asked you to protect his mail 
from his browser I'm sure you'd truthfully answer "no, we can't do that 
but we can protect the path to your mail from your browser".. I think 
not. One need only look at the wonderful marketing literature for AA to 
see what you are telling people it can do, and your above statement 
isn't consistent with that, sorry.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

Casey Schaufler wrote:

--- James Morris <[EMAIL PROTECTED]> wrote:

  

On Fri, 15 Jun 2007, Casey Schaufler wrote:



--- James Morris <[EMAIL PROTECTED]> wrote:

  
On my system, it takes about 1.2 seconds to label a fully checked out 
kernel source tree with ~23,000 files in this manner


That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
demonstrably correct (how do you do that?) for all domains
you could claim that the action is safe, if not ideal. 
I can't say if an evaluation team would buy the "safe"

argument. They've been known to balk before.
  

To clarify:

We are discussing a scheme where the underlying SELinux labeling policy 
always ensures a safe label on a file, and then relabeling newly created 
files according to their pathnames.



To counter clarify:

You are saying two things:
1. The policy always ensures a safe label.
2. Files can be relabeled in a reasonable and timely manner.

I have no questions about 2. It's a hack, but you've already
acknowledged that and it will work, allowing for some potential
cases where someone is overeager about getting a file-in-transition.

Regarding 1: This is a founding premise of the arguement, that
the "policy" is written correctly such that there is no case
where a file gets created with an unsafe label. Given the external
nature of the policy, and the number of attributes used within
the policy, and the overall sophistication of the policy mechanism,
how does one ...

a. know that a label is "safe"
b. know that a file will get a "safe" label
c. know that the policy is "correctly" written as required

The question is not if fixxerupperd can set things right.
The question is about the properly written policy that is
required to make the mechanism worth discussing.

  


There are only about 850 file type_transition rules in the policy 
shipped with RHEL and the vast majority of them are templated so this 
isn't as hard as you think. Most are things like:

  type_transition ftpd_t tmp_t : file ftpd_tmp_t;

which 1) don't require relabeling to something else and 2) very easy to 
audit. A quick look suggests that the potentially less-restrictive label 
is never chosen, for example you'll see:

  type_transition groupadd_t etc_t : file shadow_t;
  type_transition useradd_t etc_t : file shadow_t;

Instead of the default transition being etc_t they are labeled as 
shadow_t (more restrictive) and then potentially relabled to etc_t.


That said, the lack of a type_transition in this case is as important as 
having one if the default type (the parent directory) is less 
restrictive. We already have tools that analyze policy and even tools to 
warn about potential errors in policy (apol and sechecker). It might be 
a good idea to add some more analysis to these tools to point out 
potential labeling errors that can be used in automatic analysis, which 
shouldn't be hard, I'll be sure to suggest that to the setools developers.


There is no expectation that this scheme would be submitted for 
certification.



De-nial.

  


Several systems have gone off to ct&e and none of them use restorecond. 
These are custom build systems and relabeling is kept to a minimum and 
the applications are architected in a way that precludes this being 
necessary so I don't know what you are trying to get at here.


Its purpose is to merely to provide pathname-based 
labeling outside of the kernel.



If you already have an in-kernel labeling scheme that you
trust to make the world safe until you get around to doing
the labeling externally you can argue that it's good enough.
But, to quote Cinderella's Stepmother, "I said "if"".
  


The "if" for SELinux is alot easier than you suggest. It certainly 
outweighs the disadvantages of the path based scheme IMHO.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

Crispin Cowan wrote:

[EMAIL PROTECTED] wrote:
  

On Fri, 8 Jun 2007, Greg KH wrote:


I still want to see a definition of the AA "model" that we can then use
to try to implement using whatever solution works best.  As that seems
to be missing the current argument of if AA can or can not be
implemented using SELinux or something totally different should be
stopped.
  

the way I would describe the difference betwen AA and SELinux is:

SELinux is like a default allow IPS system, you have to describe
EVERYTHING to the system so that it knows what to allow and what to stop.

AA is like a default deny firewall, you describe what you want to
happen, and it blocks everything else without you even having to
realize that it's there.


That's not quite right:

* SELinux Strict Policy is a default-deny system: it specifies
  everything that is permitted system wide, and all else is denied.
* AA and the SELinux Targeted Policy are hybrid systems:
  o default-deny within a policy or profile: confined processes
are only permitted to do what the policy says, and all else
is denied.
  o default-allow system wide: unconfined processes are allowed
to do anything that classic DAC permissions allow.
  
Still not completely correct, though the targeted policy has an 
unconfined domain (unconfined_t) the policy still has allow rules for 
everything unconfined can do, 2 examples of things unconfined still 
can't do (because they aren't allowed by the targeted policy) is execmem 
and a while back when there was a /proc exploit that required setattr on 
/proc/self/environ; unconfined_t wasn't able to do that either (and 
therefore the exploit didn't work on a targeted system).


That said, the differentiation between strict and targeted is going away 
soon so that one can have some users be unconfined (but still with a few 
restrictions) and others can be fully restricted.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

[EMAIL PROTECTED] wrote:

On Sat, 9 Jun 2007, Sean wrote:


what SELinux cannot do is figure out what label to assign a new file.



Nit: SELinux figures out what to label new files fine, just not based on 
the name. This works in most cases, eg., when user_t creates a file in 
/tmp it becomes user_tmp_t, incidentally this is something that AA 
cannot handle, if the filenames aren't normalized (they normally 
aren't). For example, my ssh agent socket is stored in 
/tmp/ssh-, where the X's are random characters, AA can't 
differentiate admin ssh agents from unprivileged user ssh agents, 
showing a serious flaw in their model.


The complaint is that name-based labeling doesn't currently exist (and 
as Sean has stated that doesn't mean it _can't_ exist, just that it 
doesn't currently). In practice this has not been as big of an issue as 
you are making it out to be. Granted restorecond has a tiny race, and I 
wouldn't recommend using it on very security sensitive files but for 
usability having it relabel user_home_t to user_http_content_t isn't a 
problem (and causes no security issues).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor FAQ

[Joshua Brindle]

Crispin Cowan wrote:

David Wagner wrote:
  

James Morris  wrote:
  

[...] you can change the behavior of the application and then bypass 
policy entirely by utilizing any mechanism other than direct filesystem 
access: IPC, shared memory, Unix domain sockets, local IP networking, 
remote networking etc.

  

[...]
  


Just look at their code and their own description of AppArmor.

  

My gosh, you're right.  What the heck?  With all due respect to the
developers of AppArmor, I can't help thinking that that's pretty lame.
I think this raises substantial questions about the value of AppArmor.
What is the point of having a jail if it leaves gaping holes that
malicious code could use to escape?

And why isn't this documented clearly, with the implications fully
explained?

I would like to hear the AppArmor developers defend this design decision.
  


It was a simplicity trade off at the time, when AppArmor was mostly
aimed at servers, and there was no HAL or DBUS. Now it is definitely a
limitation that we are addressing. We are working on a mediation system
for what kind of IPC a confined process can do
http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html

  

Also, things like:

   share_mem /usr/bin/firefox r,# /bin/foo can share memory with 
/usr/bin/firefox for read only

clearly show that you aren't using native abstractions for IPC. The 
native abstraction for shared memory would be the key used when creating 
the shared memory segment. The same goes for message queues which are 
noticeably missing from the "simplified" IPC model.


This, of course, begs the question of whether you are using native 
abstractions for profiles at all, processes have nothing to do with the 
binary they started from after they've been started. The binary on disk 
could be something entirely different than the process from which it ran.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor FAQ

[Joshua Brindle]

Crispin Cowan wrote:

David Wagner wrote:
  

James Morris  wrote:
  

[...] you can change the behavior of the application and then bypass 
policy entirely by utilizing any mechanism other than direct filesystem 
access: IPC, shared memory, Unix domain sockets, local IP networking, 
remote networking etc.

  

[...]
  


Just look at their code and their own description of AppArmor.

  

My gosh, you're right.  What the heck?  With all due respect to the
developers of AppArmor, I can't help thinking that that's pretty lame.
I think this raises substantial questions about the value of AppArmor.
What is the point of having a jail if it leaves gaping holes that
malicious code could use to escape?

And why isn't this documented clearly, with the implications fully
explained?

I would like to hear the AppArmor developers defend this design decision.
  


It was a simplicity trade off at the time, when AppArmor was mostly
aimed at servers, and there was no HAL or DBUS. Now it is definitely a
limitation that we are addressing. We are working on a mediation system
for what kind of IPC a confined process can do
http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html

  
Except servers use IPC and need this access control as well. Without IPC 
and network restrictions you can't protect database servers, ldap 
servers, print servers, ssh agents, virus scanning servers, spam 
scanning servers, etc from attackers with knowledge of how to abuse the IPC.

When our IPC mediation system is code instead of vapor, it will also
appear here for review. Meanwhile, AppArmor does not make IPC security
any worse, confined processes are still subject to the usual Linux IPC
restrictions. AppArmor actually makes the IPC situation somewhat more
secure than stock Linux, e.g. normal DBUS deployment can be controlled
through file access permissions. But we are not claiming AppArmor to be
an IPC security enhancement, yet.
  
Without a security interface in DBUS similar to SELinux' apparmor won't 
be able to control who can talk to who across DBUS, only who can connect 
to DBUS directly.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor FAQ

[Joshua Brindle]

Rob Meijer wrote:

On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
  

On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:


On Mon, 16 Apr 2007, John Johansen wrote:

  

Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to the data. As the data flows
through the system, the label sticks to the data, and so security
policy with respect to this data stays intact. This is a good approach
for ensuring secrecy, the kind of problem that intelligence agencies


have.

Labels are also a good approach for ensuring integrity, which is one of
the most fundamental aspects of the security model implemented by
SELinux.

Some may infer otherwise from your document.

  

Not only that, the implication that secrecy is only useful to
intelligence agencies is pretty funny. Personally, I think that
protecting the confidentiality of my data is important (and my bank and
health care providers protecting the data they have about me). Type
Enforcement was specifically designed to be able to address integrity
_and_ confidentiality in a way acceptable to commercial organizations.

Karl



Shouldn't that be _OR_, as I have always understood confidentialy
models like BLP are by their very nature incompatible with integrity
models like Biba. Given this incompatibity, I think the idea that
BLP style use of lables (ss/* property and the likes) is only usefull
to intelligence agencies may well be correct, while usage for integrity
models like Biba and CW would be much broader than that.
  
Biba and BLP are only incompatible if they are using the same label, if 
each object has a confidentiality and integrity label they work fine 
together (as well as MLS systems work in general that is). Type 
enforcement, however, lets you accomplish both integrity and 
confidentiality (though not easily hierarchal confidentiality*). Take a 
mail client for example, I could argue that my mail is confidential so I 
label it my_mail_t and only give access to my mail client to read it and 
the MTA to write it. Further I limit access of my mail client to objects 
that can reduce its integrity such as untrusted files in /tmp, less 
trusted user home directories and so on. Despite AA advocate claims that 
info flow doesn't matter to integrity it does. I must be able to see 
what can write to objects that my mail client can read if I want to make 
any claims about its integrity.


* hierarchal confidentiality is obtained with an additional BLP label 
that is evaluated as set of constraints over the type enforcement 
permissions. SELinux is extensible in this way where AA is not.



A path based 'least priviledge' (POLP) solution would I think on its own
address neither integity nor confidentiality, and next to this would
proof to be yet an other 'fat profile' administration hell.

Having said that, I feel a path based solution could have great potential
if it could be used in conjunction with the object capability model, that
I would consider a simple and practical alternative integrity model that
does not require lables in an MLS maner, and that extends on the POLP
concept in a way that would be largely more practical.
  
This would be combining two bad systems to get a worse one IMO. 
Capability systems are inherently discretionary since propagated 
capabilities must be removed at the discretion of the possessor of the 
capabilities.


The argument that labels are not practical has yet to be shown but is 
thrown around as if it is fact. Path based systems are inferior to label 
based systems based if for no other reason than path based systems can't 
control transient objects. With policy based type transition in SELinux 
when my ssh client writes my agent socket to /tmp/ssh-xx SELinux 
calculates a type transition based off my domain to label it 
sysadm_ssh_t (or whatever is appropriate) whereas path based systems 
can't possibly control access to these objects. The same goes for any 
files written to home directories by user apps.



That is, using 'thin' path based profiles would become very practical if
all further authority can be communicated using handles in the same way
that an open file handle can be communicated.
  


Once again, this creates a discretionary system that would not work 
without modifying every single application that uses such authority (and 
trusting the code is bug free so that it does the right thing) and gives 
you an inflexible, decentralized, unmaintainable, unanalyzable policy 
since it is distributed throughout code all over the system, you give 
users no way to change the security characteristics of the system.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/