On 04/04/2016 04:44 PM, Steve Lawrence wrote:
On 04/04/2016 04:32 PM, Steve Lawrence wrote:
On 04/04/2016 03:51 PM, Dominick Grift wrote:
On 04/04/2016 09:46 PM, Daniel J Walsh wrote:
On 04/04/2016 03:15 PM, Dominick Grift wrote: On 03/29/2016 08:00
PM, Daniel J Walsh wrote:
I investigated this a little further.
manage_chr_files_pattern(svirt_sandbox_domain,
svirt_sandbox_file_t, svirt_sandbox_file_t)
define(`manage_chr_files_pattern',` allow $1 self:capability
mknod; allow $1 $2:dir rw_dir_perms; allow $1 $3:chr_file
manage_chr_file_perms; ')
Ok Makes sense but why didn't this come up with the
svirt_sandbox_domain attribute as opposed to container_t? Maybe
this is a change in cil.
I guess I should not make this the default for
svirt_sandbox_domain, and only add it for specific domains.
Thanks Dominick.
Yes that may indeed well be a CIL thing. CIL does optimization, and
this may make policy analysis a bit different. So yes, be careful when
using type attributes to query the policy. Because CIL may have "moved
rules around" for the sake of efficiency. Best to alway's, atleast
also check the rules associated with the type.
I think this is actually the expected behavior. The issue here is that a
typeattribute is used with the 'self' keyword. When this happens, the
avrule is expanded to the individual rules. For example:
allow attr self : file read;
becomes:
allow type1 type1 : file read;
allow type2 type2 : file read;
The original avrule never makes it into the policy. Using the -d flag
with sesearch will show this is the case. I don't know if 'self' with
typeattributes is a kernel limitation or not, but both CIL and
checkpolicy have the same behavior.
Ah, actually, I think the binary policy/kernel does not have a concept
of 'self' at all. Once put in the binary, this
allow type1 self : file read;
becomes
allow type1 type1 : file read;
So 'self' is essentially replaced with the source type. However, you
cannot do this replacement when source is an attribute because this
allow attr self : file read;
and this
allow attr attr : file read;
have very different meanings. So since the kernel has no concept of
self, attributes with self must be expanded.
That makes sense, so it probably worked the same was as before, anyways
I was confused,
and now I have a fix to get what I want which is a container process
with no caps.
If I write a policy file like
===============================================
policy_module(container, 1.0) gen_require(` attribute
svirt_sandbox_domain; ')
type foobar_t; domain_type(foobar_t) typeattribute foobar_t
svirt_sandbox_domain;
===============================================
I get
sesearch -A -s foobar_t | grep capa allow foobar_t foobar_t
: capability mknod ;
If I remove the typeattribute line foobar_t no longer has
mknod.
I think this is a compiler problem.
On 03/29/2016 10:53 AM, Daniel J Walsh wrote:
When I compile and install this policy
---------------------------------------------------------------
# cat /tmp/container.te policy_module(container, 1.0)
virt_sandbox_domain_template(container)
----------------------------------------------------------------
I end up with mknod capability.
sesearch -A -s container_t -t container_t -c capability
Found 1 semantic av rules: allow container_t container_t :
capability mknod ;
But I didn't add mknod to the policy.
grep mknod tmp/container.tmp class capability { chown
dac_override dac_read_search fowner fsetid kill setgid
setuid setpcap linux_immutable net_bind_service
net_broadcast net_admin net_raw ipc_lock ipc_owner
sys_module sys_rawio sys_chroot sys_ptrace sys_pacct
sys_admin sys_boot sys_nice sys_resource sys_time
sys_tty_config mknod lease audit_write audit_control
setfcap };
Any ideas?
_______________________________________________ Selinux
mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email
to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email
containing "help" to Selinux-request@xxxxxxxxxxxxx.
-- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B
6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
_______________________________________________ Selinux mailing
list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to
Selinux-leave@xxxxxxxxxxxxx. To get help, send an email
containing "help" to Selinux-request@xxxxxxxxxxxxx.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
