refpolicy: domains need access to the apt's pty and fifos

refpolicy: domains need access to the apt's pty and fifos

[Václav Ovsík]

[-- Attachment #1: Type: text/plain, Size: 6423 bytes --]

Hi,
running Debian Sid with HEAD refpolicy...
I tried to install bind9 and got some further denials for access to pty
and pipe of apt_t domain. This is a continuation of the patch from
Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
witch was about apt finally.

sid:/var/lib/dpkg/info# se_apt-get install bind9
Authenticating root.
Password: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  libbind9-30 libdns32 libisc32 libisccc30 libisccfg30 liblwres30
Suggested packages:
  bind9-doc dnsutils resolvconf
The following NEW packages will be installed:
  bind9 libbind9-30 libdns32 libisc32 libisccc30 libisccfg30 liblwres30
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 1005kB of archives.
After this operation, 2789kB of additional disk space will be used.
Get:1 http://xenbr0.localdomain sid/main libisc32 1:9.4.2-4 [126kB]
Get:2 http://xenbr0.localdomain sid/main libdns32 1:9.4.2-4 [491kB]
Get:3 http://xenbr0.localdomain sid/main libisccc30 1:9.4.2-4 [22.3kB]
Get:4 http://xenbr0.localdomain sid/main libisccfg30 1:9.4.2-4 [37.8kB]
Get:5 http://xenbr0.localdomain sid/main libbind9-30 1:9.4.2-4 [26.1kB]
Get:6 http://xenbr0.localdomain sid/main liblwres30 1:9.4.2-4 [39.5kB]
Get:7 http://xenbr0.localdomain sid/main bind9 1:9.4.2-4 [262kB]
Fetched 1005kB in 0s (3524kB/s)
Selecting previously deselected package libisc32.
(Reading database ... 68006 files and directories currently installed.)
Unpacking libisc32 (from .../libisc32_1%3a9.4.2-4_i386.deb) ...
Selecting previously deselected package libdns32.
Unpacking libdns32 (from .../libdns32_1%3a9.4.2-4_i386.deb) ...
Selecting previously deselected package libisccc30.
Unpacking libisccc30 (from .../libisccc30_1%3a9.4.2-4_i386.deb) ...
Selecting previously deselected package libisccfg30.
Unpacking libisccfg30 (from .../libisccfg30_1%3a9.4.2-4_i386.deb) ...
Selecting previously deselected package libbind9-30.
Unpacking libbind9-30 (from .../libbind9-30_1%3a9.4.2-4_i386.deb) ...
Selecting previously deselected package liblwres30.
Unpacking liblwres30 (from .../liblwres30_1%3a9.4.2-4_i386.deb) ...
Selecting previously deselected package bind9.
Unpacking bind9 (from .../bind9_1%3a9.4.2-4_i386.deb) ...
Setting up libisc32 (1:9.4.2-4) ...
Setting up libdns32 (1:9.4.2-4) ...
Setting up libisccc30 (1:9.4.2-4) ...
Setting up libisccfg30 (1:9.4.2-4) ...
Setting up libbind9-30 (1:9.4.2-4) ...
Setting up liblwres30 (1:9.4.2-4) ...
Setting up bind9 (1:9.4.2-4) ...
Adding group `bind' (GID 116) ...
Done.
Adding system user `bind' (UID 110) ...
Adding new user `bind' (UID 110) with group `bind' ...
Not creating home directory `/var/cache/bind'.
wrote key file "/etc/bind/rndc.key"
Starting domain name service...: bind.

and denials:

audit(1204723888.180:9): avc:  denied  { use } for  pid=2164 comm="groupadd" name="3" dev=devpts ino=5 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
audit(1204723888.180:10): avc:  denied  { write } for  pid=2164 comm="groupadd" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
audit(1204723888.428:11): avc:  denied  { use } for  pid=2170 comm="useradd" name="3" dev=devpts ino=5 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
audit(1204723888.428:12): avc:  denied  { write } for  pid=2170 comm="useradd" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
audit(1204723890.340:13): avc:  denied  { read write } for  pid=2235 comm="modprobe" name="3" dev=devpts ino=5 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
audit(1204723890.340:14): avc:  denied  { use } for  pid=2235 comm="modprobe" name="3" dev=devpts ino=5 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
audit(1204723890.340:15): avc:  denied  { write } for  pid=2235 comm="modprobe" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
audit(1204723890.588:16): avc:  denied  { use } for  pid=2239 comm="ifconfig" name="3" dev=devpts ino=5 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
audit(1204723890.588:17): avc:  denied  { write } for  pid=2239 comm="ifconfig" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
audit(1204723890.620:18): avc:  denied  { read write } for  pid=2240 comm="named" name="3" dev=devpts ino=5 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
audit(1204723890.620:19): avc:  denied  { use } for  pid=2240 comm="named" name="3" dev=devpts ino=5 scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
audit(1204723890.620:20): avc:  denied  { write } for  pid=2240 comm="named" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file


I tried also to install kernel image and got denials:

audit(1204727223.717:45): avc:  denied  { read write } for  pid=2844 comm="depmod" name="3" dev=devpts ino=5 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
audit(1204727223.717:46): avc:  denied  { use } for  pid=2844 comm="depmod" name="3" dev=devpts ino=5 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
audit(1204727223.717:47): avc:  denied  { write } for  pid=2844 comm="depmod" name="[99536]" dev=pipefs ino=99536 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file


Attached patch solves the most of this denials, but I doubt this is the
right way.  Should be used some attribute for this?  I noticed attribute
privfd and macro domain_interactive_fd(), what about it?  Rpm already
has such macro calls
./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)

I tried to use this macro for apt_t, and all use fd denials above are
solved with it. Should be things done in this way?

Thanks for comments.
-- 
Zito

[-- Attachment #2: apt.patch --]
[-- Type: text/x-diff, Size: 2004 bytes --]

Index: policy/modules/services/bind.te
===================================================================
--- policy/modules/services/bind.te	(revision 2631)
+++ policy/modules/services/bind.te	(working copy)
@@ -260,3 +260,9 @@
 optional_policy(`
 	ppp_dontaudit_use_fds(ndc_t)
 ')
+
+optional_policy(`
+	apt_rw_pipes(ndc_t)
+	apt_use_fds(ndc_t)
+	apt_use_ptys(ndc_t)
+')
Index: policy/modules/system/sysnetwork.te
===================================================================
--- policy/modules/system/sysnetwork.te	(revision 2631)
+++ policy/modules/system/sysnetwork.te	(working copy)
@@ -337,3 +337,9 @@
 	xen_append_log(ifconfig_t)
 	xen_dontaudit_rw_unix_stream_sockets(ifconfig_t)
 ')
+
+optional_policy(`
+	apt_rw_pipes(ifconfig_t)
+	apt_use_fds(ifconfig_t)
+	apt_use_ptys(ifconfig_t)
+')
Index: policy/modules/system/modutils.te
===================================================================
--- policy/modules/system/modutils.te	(revision 2631)
+++ policy/modules/system/modutils.te	(working copy)
@@ -158,6 +158,12 @@
 ')
 
 optional_policy(`
+	apt_rw_pipes(insmod_t)
+	apt_use_fds(insmod_t)
+	apt_use_ptys(insmod_t)
+')
+
+optional_policy(`
 	unconfined_dontaudit_rw_pipes(insmod_t)
 ')
 
@@ -226,6 +232,12 @@
 	rpm_rw_pipes(depmod_t)
 ')
 
+optional_policy(`
+	apt_rw_pipes(depmod_t)
+	apt_use_fds(depmod_t)
+	apt_use_ptys(depmod_t)
+')
+
 #################################
 #
 # update-modules local policy
Index: policy/modules/admin/usermanage.te
===================================================================
--- policy/modules/admin/usermanage.te	(revision 2631)
+++ policy/modules/admin/usermanage.te	(working copy)
@@ -253,6 +253,11 @@
 	rpm_rw_pipes(groupadd_t)
 ')
 
+optional_policy(`
+	apt_use_fds(groupadd_t)
+	apt_rw_pipes(groupadd_t)
+')
+
 ########################################
 #
 # Passwd local policy
@@ -528,3 +533,8 @@
 	rpm_use_fds(useradd_t)
 	rpm_rw_pipes(useradd_t)
 ')
+
+optional_policy(`
+	apt_use_fds(useradd_t)
+	apt_rw_pipes(useradd_t)
+')

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Erich Schubert]

Hi,
Back when I did the initial apt_t policy, I was considering to setup
domains such as apt_script_t and run the package installation scripts in
this domain. This would have been similar to the rpm_script_t domain.
However getting the files in /var/lib/dpkg/info/ labeled correctly would
probably have required some patches to dpkg. There are non-executable
files in there as well, and I'm not sure if you'd want to mix them up.
For example, there are files there storing reference md5sums, or listing
package contents. apt_script_exec_t doesn't sound appropriate for them.
But having them in the same directory means we can't use automatic file
type transitions.

The amount of things done in postinst scripts is one of the things that
really scares me from a security point of view. It might be very
valuable to use a tight SELinux policy to restrict these scripts,
however when it comes down to having a SELinux policy package update it
becomes a Catch-22 somewhat.
It would definitely help to have separate apt_t and apt_script_t
domains, though, to be able to differentiate access for installation
scripts and the package manager itself.

P.S. Thanks for the great work you've been doing on the SELinux policy
for Debian these days! THANKS!

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C   (o_
   There was never a good war or a bad peace. - Benjamin Franklin   //\
          Liebe ist eine schwere Geisteskrankheit (Platon)          V_/_


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Russell Coker]

On Thursday 06 March 2008 03:24, Erich Schubert <erich@debian.org> wrote:
> Back when I did the initial apt_t policy, I was considering to setup
> domains such as apt_script_t and run the package installation scripts in
> this domain. This would have been similar to the rpm_script_t domain.

I don't believe that it is possible to gain any security benefit from 
splitting dpkg_t, apt_t, and a domain for the scripts.

If apt decides that a certain package is to be installed then dpkg will not 
object, therefore granting apt less privileges than dpkg will not give any 
real benefit.

Pre/post install/remove scripts in Debian packages may do almost anything - 
and often do.  Any restrictions on what such scripts may do will break large 
numbers of packages.  Unless we can get changes to Debian policy relating to 
what such scripts may do (which seems quite unlikely) then we have to allow 
writing to almost all files in the system.

> The amount of things done in postinst scripts is one of the things that
> really scares me from a security point of view. It might be very
> valuable to use a tight SELinux policy to restrict these scripts,
> however when it comes down to having a SELinux policy package update it
> becomes a Catch-22 somewhat.
> It would definitely help to have separate apt_t and apt_script_t
> domains, though, to be able to differentiate access for installation
> scripts and the package manager itself.

What meaningful restrictions can be applied to one but not the other?

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Erich Schubert]

Hello Russel,
> > It would definitely help to have separate apt_t and apt_script_t
> > domains, though, to be able to differentiate access for installation
> > scripts and the package manager itself.
> What meaningful restrictions can be applied to one but not the other?

I agree with you that we would currently have to allow pretty much any
access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
obviously.
No, I can't really think of ways to restrict dpkg_script_t apart from
not messing with the dpkg_t state files. Maybe we could make some policy
that /usr is to be modified by dpkg_t only whereas dynamically generated
files have to reside in /var, but I doubt this would currently hold.
And after all, dpkg_script_t needs to be able to even add users
to /etc/passwd (although through the helper applications, not directly).

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C     (o_
 The early bird gets the worm, but the second mouse gets the cheese.  //\
       Ein Freund ist ein Geschenk, das man sich selbst macht.        V_/_


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Russell Coker]

On Thursday 06 March 2008 23:13, Erich Schubert <erich@debian.org> wrote:
> > > It would definitely help to have separate apt_t and apt_script_t
> > > domains, though, to be able to differentiate access for installation
> > > scripts and the package manager itself.
> >
> > What meaningful restrictions can be applied to one but not the other?
>
> I agree with you that we would currently have to allow pretty much any
> access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
> again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
> obviously.
> No, I can't really think of ways to restrict dpkg_script_t apart from
> not messing with the dpkg_t state files. Maybe we could make some policy

But given that dpkg_script_t can make all manner of other changes (including 
loading a SE Linux policy) it seems rather minor to restrict access to dpkg 
state files.

> that /usr is to be modified by dpkg_t only whereas dynamically generated
> files have to reside in /var, but I doubt this would currently hold.

It's a standard practice to convert the data files under /var in an upgrade.

> And after all, dpkg_script_t needs to be able to even add users
> to /etc/passwd (although through the helper applications, not directly).

Yes.

In fact while we have unconfined_t, the benefit of having a separate dpkg_t 
instead of using unconfined_t for installing packages doesn't seem 
significant.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy: domains need access to the apt's pty and fifos

[Stefan Schulze Frielinghaus]

On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> Hi,
> running Debian Sid with HEAD refpolicy...
> I tried to install bind9 and got some further denials for access to pty
> and pipe of apt_t domain. This is a continuation of the patch from
> Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> witch was about apt finally.
> 
> sid:/var/lib/dpkg/info# se_apt-get install bind9
> Authenticating root.
> Password: 
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> The following extra packages will be installed:
>   libbind9-30 libdns32 libisc32 libisccc30 libisccfg30 liblwres30
> Suggested packages:
>   bind9-doc dnsutils resolvconf
> The following NEW packages will be installed:
>   bind9 libbind9-30 libdns32 libisc32 libisccc30 libisccfg30 liblwres30
> 0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
> Need to get 1005kB of archives.
> After this operation, 2789kB of additional disk space will be used.
> Get:1 http://xenbr0.localdomain sid/main libisc32 1:9.4.2-4 [126kB]
> Get:2 http://xenbr0.localdomain sid/main libdns32 1:9.4.2-4 [491kB]
> Get:3 http://xenbr0.localdomain sid/main libisccc30 1:9.4.2-4 [22.3kB]
> Get:4 http://xenbr0.localdomain sid/main libisccfg30 1:9.4.2-4 [37.8kB]
> Get:5 http://xenbr0.localdomain sid/main libbind9-30 1:9.4.2-4 [26.1kB]
> Get:6 http://xenbr0.localdomain sid/main liblwres30 1:9.4.2-4 [39.5kB]
> Get:7 http://xenbr0.localdomain sid/main bind9 1:9.4.2-4 [262kB]
> Fetched 1005kB in 0s (3524kB/s)
> Selecting previously deselected package libisc32.
> (Reading database ... 68006 files and directories currently installed.)
> Unpacking libisc32 (from .../libisc32_1%3a9.4.2-4_i386.deb) ...
> Selecting previously deselected package libdns32.
> Unpacking libdns32 (from .../libdns32_1%3a9.4.2-4_i386.deb) ...
> Selecting previously deselected package libisccc30.
> Unpacking libisccc30 (from .../libisccc30_1%3a9.4.2-4_i386.deb) ...
> Selecting previously deselected package libisccfg30.
> Unpacking libisccfg30 (from .../libisccfg30_1%3a9.4.2-4_i386.deb) ...
> Selecting previously deselected package libbind9-30.
> Unpacking libbind9-30 (from .../libbind9-30_1%3a9.4.2-4_i386.deb) ...
> Selecting previously deselected package liblwres30.
> Unpacking liblwres30 (from .../liblwres30_1%3a9.4.2-4_i386.deb) ...
> Selecting previously deselected package bind9.
> Unpacking bind9 (from .../bind9_1%3a9.4.2-4_i386.deb) ...
> Setting up libisc32 (1:9.4.2-4) ...
> Setting up libdns32 (1:9.4.2-4) ...
> Setting up libisccc30 (1:9.4.2-4) ...
> Setting up libisccfg30 (1:9.4.2-4) ...
> Setting up libbind9-30 (1:9.4.2-4) ...
> Setting up liblwres30 (1:9.4.2-4) ...
> Setting up bind9 (1:9.4.2-4) ...
> Adding group `bind' (GID 116) ...
> Done.
> Adding system user `bind' (UID 110) ...
> Adding new user `bind' (UID 110) with group `bind' ...
> Not creating home directory `/var/cache/bind'.
> wrote key file "/etc/bind/rndc.key"
> Starting domain name service...: bind.
> 
> and denials:
> 
> audit(1204723888.180:9): avc:  denied  { use } for  pid=2164 comm="groupadd" name="3" dev=devpts ino=5 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> audit(1204723888.180:10): avc:  denied  { write } for  pid=2164 comm="groupadd" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> audit(1204723888.428:11): avc:  denied  { use } for  pid=2170 comm="useradd" name="3" dev=devpts ino=5 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> audit(1204723888.428:12): avc:  denied  { write } for  pid=2170 comm="useradd" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> audit(1204723890.340:13): avc:  denied  { read write } for  pid=2235 comm="modprobe" name="3" dev=devpts ino=5 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
> audit(1204723890.340:14): avc:  denied  { use } for  pid=2235 comm="modprobe" name="3" dev=devpts ino=5 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> audit(1204723890.340:15): avc:  denied  { write } for  pid=2235 comm="modprobe" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> audit(1204723890.588:16): avc:  denied  { use } for  pid=2239 comm="ifconfig" name="3" dev=devpts ino=5 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> audit(1204723890.588:17): avc:  denied  { write } for  pid=2239 comm="ifconfig" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> audit(1204723890.620:18): avc:  denied  { read write } for  pid=2240 comm="named" name="3" dev=devpts ino=5 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
> audit(1204723890.620:19): avc:  denied  { use } for  pid=2240 comm="named" name="3" dev=devpts ino=5 scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> audit(1204723890.620:20): avc:  denied  { write } for  pid=2240 comm="named" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> 
> 
> I tried also to install kernel image and got denials:
> 
> audit(1204727223.717:45): avc:  denied  { read write } for  pid=2844 comm="depmod" name="3" dev=devpts ino=5 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
> audit(1204727223.717:46): avc:  denied  { use } for  pid=2844 comm="depmod" name="3" dev=devpts ino=5 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> audit(1204727223.717:47): avc:  denied  { write } for  pid=2844 comm="depmod" name="[99536]" dev=pipefs ino=99536 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> 
> 
> Attached patch solves the most of this denials, but I doubt this is the
> right way.  Should be used some attribute for this?  I noticed attribute
> privfd and macro domain_interactive_fd(), what about it?  Rpm already
> has such macro calls
> ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> 
> I tried to use this macro for apt_t, and all use fd denials above are
> solved with it. Should be things done in this way?
> 
> Thanks for comments.

I think it is not really nice to have all these allow rules directly in
the modules. A similar discussion can be found here:
http://marc.info/?l=selinux&m=118707242005853&w=2

Especially the first replay of Stephen Smalley pointing out how rpm
solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)

If I had to choose between the several fixes for every module or the
"rpm-way" to allow all usage of file descriptors and read permissions
then I would vote for the latter.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy: domains need access to the apt's pty and fifos

[Christopher J. PeBenito]

On Fri, 2008-03-07 at 22:23 +0100, Stefan Schulze Frielinghaus wrote:
> On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> > Hi,
> > running Debian Sid with HEAD refpolicy...
> > I tried to install bind9 and got some further denials for access to pty
> > and pipe of apt_t domain. This is a continuation of the patch from
> > Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> > witch was about apt finally.
> > 
> > sid:/var/lib/dpkg/info# se_apt-get install bind9
> > Authenticating root.
> > Password: 
> > Reading package lists... Done
> > Building dependency tree       
> > Reading state information... Done
> > The following extra packages will be installed:
> >   libbind9-30 libdns32 libisc32 libisccc30 libisccfg30 liblwres30
> > Suggested packages:
> >   bind9-doc dnsutils resolvconf
> > The following NEW packages will be installed:
> >   bind9 libbind9-30 libdns32 libisc32 libisccc30 libisccfg30 liblwres30
> > 0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 1005kB of archives.
> > After this operation, 2789kB of additional disk space will be used.
> > Get:1 http://xenbr0.localdomain sid/main libisc32 1:9.4.2-4 [126kB]
> > Get:2 http://xenbr0.localdomain sid/main libdns32 1:9.4.2-4 [491kB]
> > Get:3 http://xenbr0.localdomain sid/main libisccc30 1:9.4.2-4 [22.3kB]
> > Get:4 http://xenbr0.localdomain sid/main libisccfg30 1:9.4.2-4 [37.8kB]
> > Get:5 http://xenbr0.localdomain sid/main libbind9-30 1:9.4.2-4 [26.1kB]
> > Get:6 http://xenbr0.localdomain sid/main liblwres30 1:9.4.2-4 [39.5kB]
> > Get:7 http://xenbr0.localdomain sid/main bind9 1:9.4.2-4 [262kB]
> > Fetched 1005kB in 0s (3524kB/s)
> > Selecting previously deselected package libisc32.
> > (Reading database ... 68006 files and directories currently installed.)
> > Unpacking libisc32 (from .../libisc32_1%3a9.4.2-4_i386.deb) ...
> > Selecting previously deselected package libdns32.
> > Unpacking libdns32 (from .../libdns32_1%3a9.4.2-4_i386.deb) ...
> > Selecting previously deselected package libisccc30.
> > Unpacking libisccc30 (from .../libisccc30_1%3a9.4.2-4_i386.deb) ...
> > Selecting previously deselected package libisccfg30.
> > Unpacking libisccfg30 (from .../libisccfg30_1%3a9.4.2-4_i386.deb) ...
> > Selecting previously deselected package libbind9-30.
> > Unpacking libbind9-30 (from .../libbind9-30_1%3a9.4.2-4_i386.deb) ...
> > Selecting previously deselected package liblwres30.
> > Unpacking liblwres30 (from .../liblwres30_1%3a9.4.2-4_i386.deb) ...
> > Selecting previously deselected package bind9.
> > Unpacking bind9 (from .../bind9_1%3a9.4.2-4_i386.deb) ...
> > Setting up libisc32 (1:9.4.2-4) ...
> > Setting up libdns32 (1:9.4.2-4) ...
> > Setting up libisccc30 (1:9.4.2-4) ...
> > Setting up libisccfg30 (1:9.4.2-4) ...
> > Setting up libbind9-30 (1:9.4.2-4) ...
> > Setting up liblwres30 (1:9.4.2-4) ...
> > Setting up bind9 (1:9.4.2-4) ...
> > Adding group `bind' (GID 116) ...
> > Done.
> > Adding system user `bind' (UID 110) ...
> > Adding new user `bind' (UID 110) with group `bind' ...
> > Not creating home directory `/var/cache/bind'.
> > wrote key file "/etc/bind/rndc.key"
> > Starting domain name service...: bind.
> > 
> > and denials:
> > 
> > audit(1204723888.180:9): avc:  denied  { use } for  pid=2164 comm="groupadd" name="3" dev=devpts ino=5 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> > audit(1204723888.180:10): avc:  denied  { write } for  pid=2164 comm="groupadd" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> > audit(1204723888.428:11): avc:  denied  { use } for  pid=2170 comm="useradd" name="3" dev=devpts ino=5 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> > audit(1204723888.428:12): avc:  denied  { write } for  pid=2170 comm="useradd" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> > audit(1204723890.340:13): avc:  denied  { read write } for  pid=2235 comm="modprobe" name="3" dev=devpts ino=5 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
> > audit(1204723890.340:14): avc:  denied  { use } for  pid=2235 comm="modprobe" name="3" dev=devpts ino=5 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> > audit(1204723890.340:15): avc:  denied  { write } for  pid=2235 comm="modprobe" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> > audit(1204723890.588:16): avc:  denied  { use } for  pid=2239 comm="ifconfig" name="3" dev=devpts ino=5 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> > audit(1204723890.588:17): avc:  denied  { write } for  pid=2239 comm="ifconfig" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> > audit(1204723890.620:18): avc:  denied  { read write } for  pid=2240 comm="named" name="3" dev=devpts ino=5 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
> > audit(1204723890.620:19): avc:  denied  { use } for  pid=2240 comm="named" name="3" dev=devpts ino=5 scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> > audit(1204723890.620:20): avc:  denied  { write } for  pid=2240 comm="named" name="[96277]" dev=pipefs ino=96277 scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> > 
> > 
> > I tried also to install kernel image and got denials:
> > 
> > audit(1204727223.717:45): avc:  denied  { read write } for  pid=2844 comm="depmod" name="3" dev=devpts ino=5 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:object_r:apt_devpts_t:s0 tclass=chr_file
> > audit(1204727223.717:46): avc:  denied  { use } for  pid=2844 comm="depmod" name="3" dev=devpts ino=5 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fd
> > audit(1204727223.717:47): avc:  denied  { write } for  pid=2844 comm="depmod" name="[99536]" dev=pipefs ino=99536 scontext=system_u:system_r:depmod_t:s0 tcontext=system_u:system_r:apt_t:s0 tclass=fifo_file
> > 
> > 
> > Attached patch solves the most of this denials, but I doubt this is the
> > right way.  Should be used some attribute for this?  I noticed attribute
> > privfd and macro domain_interactive_fd(), what about it?  Rpm already
> > has such macro calls
> > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> > 
> > I tried to use this macro for apt_t, and all use fd denials above are
> > solved with it. Should be things done in this way?
> > 
> > Thanks for comments.
> 
> I think it is not really nice to have all these allow rules directly in
> the modules. A similar discussion can be found here:
> http://marc.info/?l=selinux&m=118707242005853&w=2
> 
> Especially the first replay of Stephen Smalley pointing out how rpm
> solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)
> 
> If I had to choose between the several fixes for every module or the
> "rpm-way" to allow all usage of file descriptors and read permissions
> then I would vote for the latter.

A better option might be to mimic the inheritance of fds and pipes.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Václav Ovsík]

[-- Attachment #1: Type: text/plain, Size: 11306 bytes --]

Hi,
sorry for a delay. Beforehand thanks for all worth reactions. I'm very
thankful for these.

BTW: I found, that dpkg passes (and should not) to child processes
a file descriptor of apt pipe:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471488
The access to apts fifo should not be needed for dpkg scripts.


On Wed, Mar 05, 2008 at 05:24:28PM +0100, Erich Schubert wrote:
> Hi,
> Back when I did the initial apt_t policy, I was considering to setup
> domains such as apt_script_t and run the package installation scripts in
> this domain. This would have been similar to the rpm_script_t domain.
> However getting the files in /var/lib/dpkg/info/ labeled correctly would
> probably have required some patches to dpkg. There are non-executable
> files in there as well, and I'm not sure if you'd want to mix them up.
> For example, there are files there storing reference md5sums, or listing
> package contents. apt_script_exec_t doesn't sound appropriate for them.
> But having them in the same directory means we can't use automatic file
> type transitions.
> 
> The amount of things done in postinst scripts is one of the things that
> really scares me from a security point of view. It might be very
> valuable to use a tight SELinux policy to restrict these scripts,
> however when it comes down to having a SELinux policy package update it
> becomes a Catch-22 somewhat.
> It would definitely help to have separate apt_t and apt_script_t
> domains, though, to be able to differentiate access for installation
> scripts and the package manager itself.
> 
> P.S. Thanks for the great work you've been doing on the SELinux policy
> for Debian these days! THANKS!
> 
> best regards,
> Erich Schubert
> -- 
>     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C   (o_
>    There was never a good war or a bad peace. - Benjamin Franklin   //\
>           Liebe ist eine schwere Geisteskrankheit (Platon)          V_/_
> 

On Thu, Mar 06, 2008 at 09:17:16PM +1100, Russell Coker wrote:
> On Thursday 06 March 2008 03:24, Erich Schubert <erich@debian.org> wrote:
> > Back when I did the initial apt_t policy, I was considering to setup
> > domains such as apt_script_t and run the package installation scripts in
> > this domain. This would have been similar to the rpm_script_t domain.
> 
> I don't believe that it is possible to gain any security benefit from 
> splitting dpkg_t, apt_t, and a domain for the scripts.
> 
> If apt decides that a certain package is to be installed then dpkg will not 
> object, therefore granting apt less privileges than dpkg will not give any 
> real benefit.
> 
> Pre/post install/remove scripts in Debian packages may do almost anything - 
> and often do.  Any restrictions on what such scripts may do will break large 
> numbers of packages.  Unless we can get changes to Debian policy relating to 
> what such scripts may do (which seems quite unlikely) then we have to allow 
> writing to almost all files in the system.
> 
> > The amount of things done in postinst scripts is one of the things that
> > really scares me from a security point of view. It might be very
> > valuable to use a tight SELinux policy to restrict these scripts,
> > however when it comes down to having a SELinux policy package update it
> > becomes a Catch-22 somewhat.
> > It would definitely help to have separate apt_t and apt_script_t
> > domains, though, to be able to differentiate access for installation
> > scripts and the package manager itself.
> 
> What meaningful restrictions can be applied to one but not the other?
> 
> -- 
> russell@coker.com.au
> http://etbe.coker.com.au/          My Blog
> 
> http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

On Thu, Mar 06, 2008 at 01:13:59PM +0100, Erich Schubert wrote:
> Hello Russel,
> > > It would definitely help to have separate apt_t and apt_script_t
> > > domains, though, to be able to differentiate access for installation
> > > scripts and the package manager itself.
> > What meaningful restrictions can be applied to one but not the other?
> 
> I agree with you that we would currently have to allow pretty much any
> access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
> again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
> obviously.
> No, I can't really think of ways to restrict dpkg_script_t apart from
> not messing with the dpkg_t state files. Maybe we could make some policy
> that /usr is to be modified by dpkg_t only whereas dynamically generated
> files have to reside in /var, but I doubt this would currently hold.
> And after all, dpkg_script_t needs to be able to even add users
> to /etc/passwd (although through the helper applications, not directly).
> 
> best regards,
> Erich Schubert
> -- 
>     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C     (o_
>  The early bird gets the worm, but the second mouse gets the cheese.  //\
>        Ein Freund ist ein Geschenk, das man sich selbst macht.        V_/_
> 

On Thu, Mar 06, 2008 at 11:46:54PM +1100, Russell Coker wrote:
> On Thursday 06 March 2008 23:13, Erich Schubert <erich@debian.org> wrote:
> > > > It would definitely help to have separate apt_t and apt_script_t
> > > > domains, though, to be able to differentiate access for installation
> > > > scripts and the package manager itself.
> > >
> > > What meaningful restrictions can be applied to one but not the other?
> >
> > I agree with you that we would currently have to allow pretty much any
> > access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
> > again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
> > obviously.
> > No, I can't really think of ways to restrict dpkg_script_t apart from
> > not messing with the dpkg_t state files. Maybe we could make some policy
> 
> But given that dpkg_script_t can make all manner of other changes (including 
> loading a SE Linux policy) it seems rather minor to restrict access to dpkg 
> state files.
> 
> > that /usr is to be modified by dpkg_t only whereas dynamically generated
> > files have to reside in /var, but I doubt this would currently hold.
> 
> It's a standard practice to convert the data files under /var in an upgrade.
> 
> > And after all, dpkg_script_t needs to be able to even add users
> > to /etc/passwd (although through the helper applications, not directly).
> 
> Yes.
> 
> In fact while we have unconfined_t, the benefit of having a separate dpkg_t 
> instead of using unconfined_t for installing packages doesn't seem 
> significant.
> 
> -- 
> russell@coker.com.au
> http://etbe.coker.com.au/          My Blog
> 
> http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


Seems to me dpkg_script_t is not used now really.  Should be removed
dpkg_script_t from the refpolicy?  A part of rules should be moved from
the domain dpkg_script_t to the domain dpkg_t probably if such a removal
will take place.




On Fri, Mar 07, 2008 at 10:23:32PM +0100, Stefan Schulze Frielinghaus wrote:
> 
> On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> > Hi,
> > running Debian Sid with HEAD refpolicy...
> > I tried to install bind9 and got some further denials for access to pty
> > and pipe of apt_t domain. This is a continuation of the patch from
> > Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> > witch was about apt finally.
> > 
> > ...
> > 
> > Attached patch solves the most of this denials, but I doubt this is the
> > right way.  Should be used some attribute for this?  I noticed attribute
> > privfd and macro domain_interactive_fd(), what about it?  Rpm already
> > has such macro calls
> > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> > 
> > I tried to use this macro for apt_t, and all use fd denials above are
> > solved with it. Should be things done in this way?
> > 
> > Thanks for comments.
> 
> I think it is not really nice to have all these allow rules directly in
> the modules. A similar discussion can be found here:
> http://marc.info/?l=selinux&m=118707242005853&w=2
> 
> Especially the first replay of Stephen Smalley pointing out how rpm
> solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)
> 
> If I had to choose between the several fixes for every module or the
> "rpm-way" to allow all usage of file descriptors and read permissions
> then I would vote for the latter.
> 
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

On Mon, Mar 10, 2008 at 01:39:49PM -0400, Christopher J. PeBenito wrote:
> On Fri, 2008-03-07 at 22:23 +0100, Stefan Schulze Frielinghaus wrote:
> > On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> > > Hi,
> > > running Debian Sid with HEAD refpolicy...
> > > I tried to install bind9 and got some further denials for access to pty
> > > and pipe of apt_t domain. This is a continuation of the patch from
> > > Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> > > witch was about apt finally.
> > > 
> > > ...
> > > 
> > > Attached patch solves the most of this denials, but I doubt this is the
> > > right way.  Should be used some attribute for this?  I noticed attribute
> > > privfd and macro domain_interactive_fd(), what about it?  Rpm already
> > > has such macro calls
> > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> > > 
> > > I tried to use this macro for apt_t, and all use fd denials above are
> > > solved with it. Should be things done in this way?
> > > 
> > > Thanks for comments.
> > 
> > I think it is not really nice to have all these allow rules directly in
> > the modules. A similar discussion can be found here:
> > http://marc.info/?l=selinux&m=118707242005853&w=2
> > 
> > Especially the first replay of Stephen Smalley pointing out how rpm
> > solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)
> > 
> > If I had to choose between the several fixes for every module or the
> > "rpm-way" to allow all usage of file descriptors and read permissions
> > then I would vote for the latter.
> 
> A better option might be to mimic the inheritance of fds and pipes.

I'm not certain I understood this correctly.  I understood `to mimic the
inheritance', that for all domains runnable from dpkg scripts should be
inserted appropriate rules for access explicitly.  If I'm wrong, please
explain it a bit further.  Sorry for my English.

Please, can you look at the attached patch snippet? The interface
identifier needs review.

Finaly I wrote apt_rw_pipes() to be consistent with the assignment/ident
of interface, although in our case (dpkg scripts) the access to apt pipe
should not be allowed. Maybe some regular child can comunicate with apt
through a pipe and can be run from dpkg script equally. Who knows :)
The interface apt_dontaudit_write_pipes() is useless than and may be
discarded.

If things are ok, I will try to search all possible domains runnable
from a dpkg script and will prepare the complete patch.

Thanks
-- 
Zito

[-- Attachment #2: apt --]
[-- Type: text/plain, Size: 1698 bytes --]

Index: policy/modules/system/libraries.te
===================================================================
--- policy/modules/system/libraries.te.orig	2008-03-20 12:01:18.000000000 +0100
+++ policy/modules/system/libraries.te	2008-03-20 15:58:45.000000000 +0100
@@ -103,9 +103,7 @@
 ')
 
 optional_policy(`
-	apt_rw_pipes(ldconfig_t)
-	apt_use_fds(ldconfig_t)
-	apt_use_ptys(ldconfig_t)
+	apt_allow_inherited_resrc(ldconfig_t)
 ')
 
 optional_policy(`
Index: policy/modules/admin/apt.if
===================================================================
--- policy/modules/admin/apt.if.orig	2008-03-20 12:00:47.000000000 +0100
+++ policy/modules/admin/apt.if	2008-03-20 15:57:47.000000000 +0100
@@ -92,6 +92,24 @@
 
 ########################################
 ## <summary>
+##	Do not audit attempts to write apt unnamed pipes.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	The type of the process performing this action.
+##	</summary>
+## </param>
+#
+interface(`apt_dontaudit_write_pipes',`
+	gen_require(`
+		type apt_t;
+	')
+
+	dontaudit $1 apt_t:fifo_file write;
+')
+
+########################################
+## <summary>
 ##	Read and write an unnamed apt pipe.
 ## </summary>
 ## <param name="domain">
@@ -190,3 +208,19 @@
 	dontaudit $1 apt_var_lib_t:file manage_file_perms;
 	dontaudit $1 apt_var_lib_t:lnk_file manage_lnk_perms;
 ')
+
+########################################
+## <summary>
+##	Allow use, read & write to inherited apts fds, pty & pipes.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`apt_allow_inherited_resrc',`
+	apt_rw_pipes($1)
+	apt_use_fds($1)
+	apt_use_ptys($1)
+')

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Christopher J. PeBenito]

On Fri, 2008-03-21 at 08:31 +0100, Václav Ovsík wrote:
> Hi,
> sorry for a delay. Beforehand thanks for all worth reactions. I'm very
> thankful for these.
> 
> BTW: I found, that dpkg passes (and should not) to child processes
> a file descriptor of apt pipe:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471488
> The access to apts fifo should not be needed for dpkg scripts.

> On Thu, Mar 06, 2008 at 11:46:54PM +1100, Russell Coker wrote:
> > On Thursday 06 March 2008 23:13, Erich Schubert <erich@debian.org> wrote:
> > > > > It would definitely help to have separate apt_t and apt_script_t
> > > > > domains, though, to be able to differentiate access for installation
> > > > > scripts and the package manager itself.
> > > >
> > > > What meaningful restrictions can be applied to one but not the other?
> > >
> > > I agree with you that we would currently have to allow pretty much any
> > > access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
> > > again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
> > > obviously.
> > > No, I can't really think of ways to restrict dpkg_script_t apart from
> > > not messing with the dpkg_t state files. Maybe we could make some policy
> > 
> > But given that dpkg_script_t can make all manner of other changes (including 
> > loading a SE Linux policy) it seems rather minor to restrict access to dpkg 
> > state files.
> > 
> > > that /usr is to be modified by dpkg_t only whereas dynamically generated
> > > files have to reside in /var, but I doubt this would currently hold.
> > 
> > It's a standard practice to convert the data files under /var in an upgrade.
> > 
> > > And after all, dpkg_script_t needs to be able to even add users
> > > to /etc/passwd (although through the helper applications, not directly).
> > 
> > Yes.
> > 
> > In fact while we have unconfined_t, the benefit of having a separate dpkg_t 
> > instead of using unconfined_t for installing packages doesn't seem 
> > significant.

> Seems to me dpkg_script_t is not used now really.  Should be removed
> dpkg_script_t from the refpolicy?  A part of rules should be moved from
> the domain dpkg_script_t to the domain dpkg_t probably if such a removal
> will take place.

As I recall it was a work in progress by either Erich or Manoj.  If it
was never finished or abandoned, then it should probably be removed.


> On Mon, Mar 10, 2008 at 01:39:49PM -0400, Christopher J. PeBenito wrote:
> > On Fri, 2008-03-07 at 22:23 +0100, Stefan Schulze Frielinghaus wrote:
> > > On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> > > > Hi,
> > > > running Debian Sid with HEAD refpolicy...
> > > > I tried to install bind9 and got some further denials for access to pty
> > > > and pipe of apt_t domain. This is a continuation of the patch from
> > > > Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> > > > witch was about apt finally.
> > > > 
> > > > ...
> > > > 
> > > > Attached patch solves the most of this denials, but I doubt this is the
> > > > right way.  Should be used some attribute for this?  I noticed attribute
> > > > privfd and macro domain_interactive_fd(), what about it?  Rpm already
> > > > has such macro calls
> > > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> > > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> > > > 
> > > > I tried to use this macro for apt_t, and all use fd denials above are
> > > > solved with it. Should be things done in this way?
> > > > 
> > > > Thanks for comments.
> > > 
> > > I think it is not really nice to have all these allow rules directly in
> > > the modules. A similar discussion can be found here:
> > > http://marc.info/?l=selinux&m=118707242005853&w=2
> > > 
> > > Especially the first replay of Stephen Smalley pointing out how rpm
> > > solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)
> > > 
> > > If I had to choose between the several fixes for every module or the
> > > "rpm-way" to allow all usage of file descriptors and read permissions
> > > then I would vote for the latter.
> > 
> > A better option might be to mimic the inheritance of fds and pipes.
> 
> I'm not certain I understood this correctly.  I understood `to mimic the
> inheritance', that for all domains runnable from dpkg scripts should be
> inserted appropriate rules for access explicitly.  If I'm wrong, please
> explain it a bit further.  Sorry for my English.

No thats not what I mean.  If you do that, then it means each module has
to know about domains that indirectly execute it.  My suggestion is if
you have a chain of execs like this:

user -> foo -> bar -> yar

then you would want yar to inherit and use user's fds so that it can
write out to the user's terminal.  So it seems best to structure the
policy so that at each run interface call you put in your own fd and
pipes and also the pipes and fds that you've inherited.  So that results
in:

foo inherits user fds/pipes
bar inherits user and foo fds/pipes
yar inherits user, bar, and foo pipes

I managed to partially do this with roles and terminals, in run
interfaces.  My initial idea is for each domain to keep an attribute of
fds and redirections that it inherits.  Unfortunately this turns run
interfaces ugly due to fds possibly opened to a file, pipe, or terminal
(I suppose there could be other redirections but these are by far the
common ones).  For example (in pseudo-policy)

interface foo_run
	foo_domtrans($domain)
	roleattribute foo_inherited_roles $role;
	typeattribute foo_inherited_fds $inherit_fds;
	typeattribute foo_inherited_terms $inherit_terms;
	typeattribute foo_inherited_pipes $inherit_pipes;

Then in foo.te we have

role foo_inherited_roles types foo_t;
allow foo_t foo_inh_fds:fd use;
allow foo_t foo_inh_files:file rw_file_perms;
allow foo_t foo_inh_terms:chr_file rw_chr_file_perms;
allow foo_t foo_inh_pipes:fifo_file rw_fifo_file_perms;

bar_run(foo_t,
	foo_inh_roles,
	{ foo_t foo_inh_fds },
	{ foo_t foo_inh_pipes },
	foo_inh_files,
	foo_inh_terms
	)

if foo opens up a pty for its call to bar then we could break most of
the inheritance

bar_run(foo_t,foo_inh_roles,foo_t,,,foo_pty_t)

The problem is that not all of the constructs I used in my example are
available in the current language, and optional parameters on interfaces
are not currently allowed.

Its not so pretty, but thats my idea.  I'm certainly open to suggestions
for something better.  In the mean time I suppose we just have to
continue adding rules to the individual modules.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Martin Orr]

On 26/03/08 15:57, Christopher J. PeBenito wrote:
> On Fri, 2008-03-21 at 08:31 +0100, Václav Ovsík wrote:
>> BTW: I found, that dpkg passes (and should not) to child processes
>> a file descriptor of apt pipe:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471488
>> The access to apts fifo should not be needed for dpkg scripts.

Ah, that explains a lot.

>> On Thu, Mar 06, 2008 at 11:46:54PM +1100, Russell Coker wrote:
>>> On Thursday 06 March 2008 23:13, Erich Schubert <erich@debian.org> wrote:
>>>>>> It would definitely help to have separate apt_t and apt_script_t
>>>>>> domains, though, to be able to differentiate access for installation
>>>>>> scripts and the package manager itself.
>>>>> What meaningful restrictions can be applied to one but not the other?
>>>> I agree with you that we would currently have to allow pretty much any
>>>> access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
>>>> again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
>>>> obviously.
>>>> No, I can't really think of ways to restrict dpkg_script_t apart from
>>>> not messing with the dpkg_t state files. Maybe we could make some policy
>>> But given that dpkg_script_t can make all manner of other changes (including 
>>> loading a SE Linux policy) it seems rather minor to restrict access to dpkg 
>>> state files.
>>>
>>>> that /usr is to be modified by dpkg_t only whereas dynamically generated
>>>> files have to reside in /var, but I doubt this would currently hold.
>>> It's a standard practice to convert the data files under /var in an upgrade.
>>>
>>>> And after all, dpkg_script_t needs to be able to even add users
>>>> to /etc/passwd (although through the helper applications, not directly).
>>> Yes.
>>>
>>> In fact while we have unconfined_t, the benefit of having a separate dpkg_t 
>>> instead of using unconfined_t for installing packages doesn't seem 
>>> significant.
> 
>> Seems to me dpkg_script_t is not used now really.  Should be removed
>> dpkg_script_t from the refpolicy?  A part of rules should be moved from
>> the domain dpkg_script_t to the domain dpkg_t probably if such a removal
>> will take place.
> 
> As I recall it was a work in progress by either Erich or Manoj.  If it
> was never finished or abandoned, then it should probably be removed.

Because of
dpkg_domtrans_script(dpkg_t)
maintainer scripts written in shell (i.e. most) are run in dpkg_script_t,
but any written in something else (usually Perl) stay in dpkg_t.  So at the
moment a bunch of rules are needed for both domains, which is not very sensible.

-- 
Martin Orr

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [DSE-Dev] refpolicy: domains need access to the apt's pty and fifos

[Václav Ovsík]

[-- Attachment #1: Type: text/plain, Size: 9055 bytes --]

Hi,

On Wed, Mar 26, 2008 at 11:57:09AM -0400, Christopher J. PeBenito wrote:
> 
> On Fri, 2008-03-21 at 08:31 +0100, Václav Ovsík wrote:
> > Hi,
> > sorry for a delay. Beforehand thanks for all worth reactions. I'm very
> > thankful for these.
> > 
> > BTW: I found, that dpkg passes (and should not) to child processes
> > a file descriptor of apt pipe:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471488
> > The access to apts fifo should not be needed for dpkg scripts.
> 
> > On Thu, Mar 06, 2008 at 11:46:54PM +1100, Russell Coker wrote:
> > > On Thursday 06 March 2008 23:13, Erich Schubert <erich@debian.org> wrote:
> > > > > > It would definitely help to have separate apt_t and apt_script_t
> > > > > > domains, though, to be able to differentiate access for installation
> > > > > > scripts and the package manager itself.
> > > > >
> > > > > What meaningful restrictions can be applied to one but not the other?
> > > >
> > > > I agree with you that we would currently have to allow pretty much any
> > > > access by apt_script_t, unfortunately. Sorry for mixing up apt and dpkg
> > > > again in that post btw, yes, it sould be dpkg_t and dpkg_script_t,
> > > > obviously.
> > > > No, I can't really think of ways to restrict dpkg_script_t apart from
> > > > not messing with the dpkg_t state files. Maybe we could make some policy
> > > 
> > > But given that dpkg_script_t can make all manner of other changes (including 
> > > loading a SE Linux policy) it seems rather minor to restrict access to dpkg 
> > > state files.
> > > 
> > > > that /usr is to be modified by dpkg_t only whereas dynamically generated
> > > > files have to reside in /var, but I doubt this would currently hold.
> > > 
> > > It's a standard practice to convert the data files under /var in an upgrade.
> > > 
> > > > And after all, dpkg_script_t needs to be able to even add users
> > > > to /etc/passwd (although through the helper applications, not directly).
> > > 
> > > Yes.
> > > 
> > > In fact while we have unconfined_t, the benefit of having a separate dpkg_t 
> > > instead of using unconfined_t for installing packages doesn't seem 
> > > significant.
> 
> > Seems to me dpkg_script_t is not used now really.  Should be removed
> > dpkg_script_t from the refpolicy?  A part of rules should be moved from
> > the domain dpkg_script_t to the domain dpkg_t probably if such a removal
> > will take place.
> 
> As I recall it was a work in progress by either Erich or Manoj.  If it
> was never finished or abandoned, then it should probably be removed.
> 
> 
> > On Mon, Mar 10, 2008 at 01:39:49PM -0400, Christopher J. PeBenito wrote:
> > > On Fri, 2008-03-07 at 22:23 +0100, Stefan Schulze Frielinghaus wrote:
> > > > On Wed, 2008-03-05 at 16:23 +0100, Václav Ovsík wrote:
> > > > > Hi,
> > > > > running Debian Sid with HEAD refpolicy...
> > > > > I tried to install bind9 and got some further denials for access to pty
> > > > > and pipe of apt_t domain. This is a continuation of the patch from
> > > > > Martin Orr in thread "refpolicy: patch for ldconfig from glibc 2.7...",
> > > > > witch was about apt finally.
> > > > > 
> > > > > ...
> > > > > 
> > > > > Attached patch solves the most of this denials, but I doubt this is the
> > > > > right way.  Should be used some attribute for this?  I noticed attribute
> > > > > privfd and macro domain_interactive_fd(), what about it?  Rpm already
> > > > > has such macro calls
> > > > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_t)
> > > > > ./policy/modules/admin/rpm.te:domain_interactive_fd(rpm_script_t)
> > > > > 
> > > > > I tried to use this macro for apt_t, and all use fd denials above are
> > > > > solved with it. Should be things done in this way?
> > > > > 
> > > > > Thanks for comments.
> > > > 
> > > > I think it is not really nice to have all these allow rules directly in
> > > > the modules. A similar discussion can be found here:
> > > > http://marc.info/?l=selinux&m=118707242005853&w=2
> > > > 
> > > > Especially the first replay of Stephen Smalley pointing out how rpm
> > > > solves this via domain.if: rpm_use_fds($1) and rpm_read_pipes($1)
> > > > 
> > > > If I had to choose between the several fixes for every module or the
> > > > "rpm-way" to allow all usage of file descriptors and read permissions
> > > > then I would vote for the latter.
> > > 
> > > A better option might be to mimic the inheritance of fds and pipes.
> > 
> > I'm not certain I understood this correctly.  I understood `to mimic the
> > inheritance', that for all domains runnable from dpkg scripts should be
> > inserted appropriate rules for access explicitly.  If I'm wrong, please
> > explain it a bit further.  Sorry for my English.
> 
> No thats not what I mean.  If you do that, then it means each module has
> to know about domains that indirectly execute it.  My suggestion is if
> you have a chain of execs like this:
> 
> user -> foo -> bar -> yar
> 
> then you would want yar to inherit and use user's fds so that it can
> write out to the user's terminal.  So it seems best to structure the
> policy so that at each run interface call you put in your own fd and
> pipes and also the pipes and fds that you've inherited.  So that results
> in:
> 
> foo inherits user fds/pipes
> bar inherits user and foo fds/pipes
> yar inherits user, bar, and foo pipes
> 
> I managed to partially do this with roles and terminals, in run
> interfaces.  My initial idea is for each domain to keep an attribute of
> fds and redirections that it inherits.  Unfortunately this turns run
> interfaces ugly due to fds possibly opened to a file, pipe, or terminal
> (I suppose there could be other redirections but these are by far the
> common ones).  For example (in pseudo-policy)
> 
> interface foo_run
> 	foo_domtrans($domain)
> 	roleattribute foo_inherited_roles $role;
> 	typeattribute foo_inherited_fds $inherit_fds;
> 	typeattribute foo_inherited_terms $inherit_terms;
> 	typeattribute foo_inherited_pipes $inherit_pipes;
> 
> Then in foo.te we have
> 
> role foo_inherited_roles types foo_t;
> allow foo_t foo_inh_fds:fd use;
> allow foo_t foo_inh_files:file rw_file_perms;
> allow foo_t foo_inh_terms:chr_file rw_chr_file_perms;
> allow foo_t foo_inh_pipes:fifo_file rw_fifo_file_perms;
> 
> bar_run(foo_t,
> 	foo_inh_roles,
> 	{ foo_t foo_inh_fds },
> 	{ foo_t foo_inh_pipes },
> 	foo_inh_files,
> 	foo_inh_terms
> 	)
> 
> if foo opens up a pty for its call to bar then we could break most of
> the inheritance
> 
> bar_run(foo_t,foo_inh_roles,foo_t,,,foo_pty_t)
> 
> The problem is that not all of the constructs I used in my example are
> available in the current language, and optional parameters on interfaces
> are not currently allowed.
> 
> Its not so pretty, but thats my idea.  I'm certainly open to suggestions
> for something better.  In the mean time I suppose we just have to
> continue adding rules to the individual modules.

Thanks for the exhaustive explanation Christopher. It seemed to me, that
your idea can be done at least for types (a roleattribute keyword not
exist yet), but I was wrong about attributes :(. Attribute can't have
attribute (recursively). With an attached nonfunctional patch I ended
with:

/usr/bin/checkmodule -M -m tmp/apt.tmp -o tmp/apt.mod
/usr/bin/checkmodule:  loading policy configuration from tmp/apt.tmp
policy/modules/admin/apt.te":135:ERROR 'unknown type dpkg_inherited_fd' at token ';' on line 7686:
        typeattribute dpkg_inherited_fd apt_inherited_fd;
#line 135
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/apt.mod] Error 1

Of course dpkg_inherited_fd is the attribute and not the type, shame.
You are right, with current policy language this can't be done easily.

Maybe wee can do this job using m4. This would require an additional
pass to process sources or modification of processing a bit. My rough
idea for modular policy:
    * To include the third new parameter of interface/template macro
      used by run interfaces. This parameter will accept what and how
      should be inherited in some notation parse able fine by m4. The
      information "what" should describe the class (fd, pipe...), the
      type. The information "how" should describe passing down (to pass
      inheritance down or to stop inheritance there).
    * To split module preprocessing (m4) and compilation (checkmodule)
      (Rules.modular).
    * All modules must by m4 processed at first to create the
      meta-information about all inheritances. The compilation
      (checkmodule) of any module (with some run interface) should
      depend on meta-information from all other packages.
    * Updating of inheritance meta-information must be updated only when
      the content is really different, so Make will not restart
      rebuilding things unnecessarily.
    * To build allow rules from inheritance meta-information and append
      this rules to already preprocessed .te product and compile it by
      checkmodule.

Please comment this. Thanks.
Best Regards
-- 
Zito

[-- Attachment #2: apt --]
[-- Type: text/plain, Size: 16650 bytes --]

---
 policy/modules/admin/apt.if          |   46 ++++++++++++++++++++++++++---
 policy/modules/admin/apt.te          |    7 ++++
 policy/modules/admin/dpkg.if         |   30 +++++++++++++++----
 policy/modules/admin/dpkg.te         |   18 +++++++----
 policy/modules/admin/rpm.if          |    2 -
 policy/modules/system/libraries.if   |   27 ++++++++++++++---
 policy/modules/system/libraries.te   |   12 +++----
 policy/modules/system/selinuxutil.if |   54 +++++++++++++++++++++++++++++------
 policy/modules/system/selinuxutil.te |   10 ++++++
 policy/modules/system/unconfined.te  |    2 -
 policy/modules/system/userdomain.if  |    4 +-
 policy/modules/system/userdomain.te  |    6 +--
 policy/support/loadable_module.spt   |   41 ++++++++++++++++++++++++++
 13 files changed, 216 insertions(+), 43 deletions(-)

Index: policy/modules/system/libraries.te
===================================================================
--- policy/modules/system/libraries.te.orig	2008-04-22 16:00:22.000000000 +0200
+++ policy/modules/system/libraries.te	2008-04-22 16:00:22.000000000 +0200
@@ -42,6 +42,9 @@
 type textrel_shlib_t alias texrel_shlib_t;
 files_type(textrel_shlib_t)
 
+# declarations for inherited resources
+decl_inh_resources(ldconfig)
+
 ########################################
 #
 # ldconfig local policy
@@ -85,6 +88,9 @@
 
 userdom_use_all_users_fds(ldconfig_t)
 
+# allow access to inherited resources
+rules_inh_resources(ldconfig_t, ldconfig)
+
 ifdef(`distro_ubuntu',`
 	optional_policy(`
 		unconfined_domain(ldconfig_t)
@@ -103,12 +109,6 @@
 ')
 
 optional_policy(`
-	apt_rw_pipes(ldconfig_t)
-	apt_use_fds(ldconfig_t)
-	apt_use_ptys(ldconfig_t)
-')
-
-optional_policy(`
 	# When you install a kernel the postinstall builds a initrd image in tmp 
 	# and executes ldconfig on it.  If you dont allow this kernel installs 
 	# blow up.
Index: policy/modules/admin/apt.if
===================================================================
--- policy/modules/admin/apt.if.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/admin/apt.if	2008-04-22 16:15:23.000000000 +0200
@@ -34,9 +34,24 @@
 ##	The role to allow the apt domain.
 ##	</summary>
 ## </param>
-## <param name="terminal">
+## <param name="fds">
 ##	<summary>
-##	The type of the terminal allow the apt domain to use.
+##	Types of fds to allow the apt domain to use.
+##	</summary>
+## </param>
+## <param name="pipes">
+##	<summary>
+##	Types of pipes to allow the apt domain to use.
+##	</summary>
+## </param>
+## <param name="files">
+##	<summary>
+##	Types of files to allow the apt domain to use.
+##	</summary>
+## </param>
+## <param name="terminals">
+##	<summary>
+##	Types of terminals to allow the apt domain to use.
 ##	</summary>
 ## </param>
 ## <rolecap/>
@@ -44,12 +59,15 @@
 interface(`apt_run',`
 	gen_require(`
 		type apt_t;
+		decl_inh_resources(apt)
 	')
 
 	apt_domtrans($1)
-	role $2 types apt_t;
-	allow apt_t $3:chr_file rw_term_perms;
-	# TODO: likely have to add dpkg_run here.
+	role_opt_types(`$2', apt_t)
+	attribute_types_opt(apt_inherited_fd, `$3')
+	attribute_types_opt(apt_inherited_pipe, `$4')
+	attribute_types_opt(apt_inherited_file, `$5')
+	attribute_types_opt(apt_inherited_terminal, `$6')
 ')
 
 ########################################
@@ -92,6 +110,24 @@
 
 ########################################
 ## <summary>
+##	Do not audit attempts to write apt unnamed pipes.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	The type of the process performing this action.
+##	</summary>
+## </param>
+#
+interface(`apt_dontaudit_write_pipes',`
+	gen_require(`
+		type apt_t;
+	')
+
+	dontaudit $1 apt_t:fifo_file write;
+')
+
+########################################
+## <summary>
 ##	Read and write an unnamed apt pipe.
 ## </summary>
 ## <param name="domain">
Index: policy/modules/admin/apt.te
===================================================================
--- policy/modules/admin/apt.te.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/admin/apt.te	2008-04-22 16:00:22.000000000 +0200
@@ -33,6 +33,9 @@
 type apt_var_log_t;
 logging_log_file(apt_var_log_t)
 
+# declarations for inherited resources
+decl_inh_resources(apt)
+
 ########################################
 #
 # apt Local policy
@@ -121,6 +124,9 @@
 
 sysnet_read_config(apt_t)
 
+# allow access to inherited resources
+rules_inh_resources(apt_t, apt)
+
 # with boolean, for cron-apt and such?
 #optional_policy(`
 #	cron_system_entry(apt_t,apt_exec_t)
@@ -131,6 +137,7 @@
 	dpkg_read_db(apt_t)
 	dpkg_domtrans(apt_t)
 	dpkg_lock_db(apt_t)
+	dpkg_run(apt_t, , apt_inherited_fd, apt_inherited_pipe, apt_inherited_file, apt_inherited_terminal)
 ')
 
 optional_policy(`
Index: policy/modules/admin/dpkg.if
===================================================================
--- policy/modules/admin/dpkg.if.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/admin/dpkg.if	2008-04-22 16:15:47.000000000 +0200
@@ -58,9 +58,24 @@
 ##	The role to allow the dpkg domain.
 ##	</summary>
 ## </param>
-## <param name="terminal">
+## <param name="fds">
 ##	<summary>
-##	The type of the terminal allow the dpkg domain to use.
+##	Types of fds to allow the dpkg domain to use.
+##	</summary>
+## </param>
+## <param name="pipes">
+##	<summary>
+##	Types of pipes to allow the dpkg domain to use.
+##	</summary>
+## </param>
+## <param name="files">
+##	<summary>
+##	Types of files to allow the dpkg domain to use.
+##	</summary>
+## </param>
+## <param name="terminals">
+##	<summary>
+##	Types of terminals to allow the dpkg domain to use.
 ##	</summary>
 ## </param>
 ## <rolecap/>
@@ -68,13 +83,16 @@
 interface(`dpkg_run',`
 	gen_require(`
 		type dpkg_t, dpkg_script_t;
+		decl_inh_resources(dpkg)
 	')
 
 	dpkg_domtrans($1)
-	role $2 types dpkg_t;
-	role $2 types dpkg_script_t;
-	seutil_run_loadpolicy(dpkg_script_t,$2,$3)
-	allow dpkg_t $3:chr_file rw_term_perms;
+	role_opt_types(`$2', dpkg_t)
+	role_opt_types(`$2', dpkg_script_t)
+	attribute_types_opt(dpkg_inherited_fd, `$3')
+	attribute_types_opt(dpkg_inherited_pipe, `$4')
+	attribute_types_opt(dpkg_inherited_file, `$5')
+	attribute_types_opt(dpkg_inherited_terminal, `$6')
 ')
 
 ########################################
Index: policy/modules/admin/dpkg.te
===================================================================
--- policy/modules/admin/dpkg.te.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/admin/dpkg.te	2008-04-22 16:00:22.000000000 +0200
@@ -47,6 +47,9 @@
 type dpkg_script_tmpfs_t;
 files_tmpfs_file(dpkg_script_tmpfs_t)
 
+# declarations for inherited resources
+decl_inh_resources(dpkg)
+
 ########################################
 #
 # dpkg Local policy
@@ -173,9 +176,8 @@
 # since the scripts aren't labeled correctly yet...
 allow dpkg_t dpkg_var_lib_t:file execute;
 
-optional_policy(`
-	apt_use_ptys(dpkg_t)
-')
+# allow access to inherited resources
+rules_inh_resources(dpkg_t, dpkg)
 
 # TODO: allow?
 #optional_policy(`
@@ -319,10 +321,12 @@
 	allow dpkg_script_t self:process execmem;
 ')
 
-optional_policy(`
-	apt_rw_pipes(dpkg_script_t)
-	apt_use_fds(dpkg_script_t)
-')
+# allow access to inherited resources
+rules_inh_resources(dpkg_script_t, dpkg)
+
+# dpkg can run (scripts)
+libs_run_ldconfig(dpkg_script_t, , dpkg_inherited_fd, dpkg_inherited_pipe, dpkg_inherited_file, dpkg_inherited_terminal)
+seutil_run_loadpolicy(dpkg_script_t, , dpkg_inherited_fd, dpkg_inherited_pipe, dpkg_inherited_file, dpkg_inherited_terminal)
 
 optional_policy(`
 	bootloader_domtrans(dpkg_script_t)
Index: policy/modules/system/libraries.if
===================================================================
--- policy/modules/system/libraries.if.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/system/libraries.if	2008-04-22 16:16:18.000000000 +0200
@@ -33,9 +33,24 @@
 ##	The role to allow the ldconfig domain.
 ##	</summary>
 ## </param>
-## <param name="terminal">
+## <param name="fds">
 ##	<summary>
-##	The type of the terminal allow the ldconfig domain to use.
+##	Types of fds to allow the ldconfig domain to use.
+##	</summary>
+## </param>
+## <param name="pipes">
+##	<summary>
+##	Types of pipes to allow the ldconfig domain to use.
+##	</summary>
+## </param>
+## <param name="files">
+##	<summary>
+##	Types of files to allow the ldconfig domain to use.
+##	</summary>
+## </param>
+## <param name="terminals">
+##	<summary>
+##	Types of terminals to allow the ldconfig domain to use.
 ##	</summary>
 ## </param>
 ## <rolecap/>
@@ -43,11 +58,15 @@
 interface(`libs_run_ldconfig',`
 	gen_require(`
 		type ldconfig_t;
+		decl_inh_resources(ldconfig)
 	')
 
 	libs_domtrans_ldconfig($1)
-	role $2 types ldconfig_t;
-	allow ldconfig_t $3:chr_file rw_term_perms;
+	role_opt_types(`$2', ldconfig_t)
+	attribute_types_opt(ldconfig_inherited_fd, `$3')
+	attribute_types_opt(ldconfig_inherited_pipe, `$4')
+	attribute_types_opt(ldconfig_inherited_file, `$5')
+	attribute_types_opt(ldconfig_inherited_terminal, `$6')
 ')
 
 ########################################
Index: policy/modules/system/unconfined.te
===================================================================
--- policy/modules/system/unconfined.te.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/system/unconfined.te	2008-04-22 16:00:22.000000000 +0200
@@ -36,7 +36,7 @@
 
 init_run_daemon(unconfined_t, unconfined_r, { unconfined_devpts_t unconfined_tty_device_t })
 
-libs_run_ldconfig(unconfined_t, unconfined_r, { unconfined_devpts_t unconfined_tty_device_t })
+libs_run_ldconfig(unconfined_t, unconfined_r, , , , { unconfined_devpts_t unconfined_tty_device_t })
 
 logging_send_syslog_msg(unconfined_t)
 logging_run_auditctl(unconfined_t, unconfined_r, { unconfined_devpts_t unconfined_tty_device_t })
Index: policy/modules/system/userdomain.te
===================================================================
--- policy/modules/system/userdomain.te.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/system/userdomain.te	2008-04-22 16:00:22.000000000 +0200
@@ -243,7 +243,7 @@
 ')
 
 optional_policy(`
-	apt_run(sysadm_t, sysadm_r, admin_terminal)
+	apt_run(sysadm_t, sysadm_r, , , , admin_terminal)
 ')
 
 optional_policy(`
@@ -313,7 +313,7 @@
 ')
 
 optional_policy(`
-	dpkg_run(sysadm_t, sysadm_r, admin_terminal)
+	dpkg_run(sysadm_t, sysadm_r, , , , admin_terminal)
 ')
 
 optional_policy(`
@@ -348,7 +348,7 @@
 ')
 
 optional_policy(`
-	libs_run_ldconfig(sysadm_t, sysadm_r, admin_terminal)
+	libs_run_ldconfig(sysadm_t, sysadm_r, , , , admin_terminal)
 ')
 
 optional_policy(`
Index: policy/support/loadable_module.spt
===================================================================
--- policy/support/loadable_module.spt.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/support/loadable_module.spt	2008-04-22 16:00:22.000000000 +0200
@@ -149,3 +149,44 @@
 		$3
 	')}
 ')
+
+##############################
+#
+# Optional role types handling
+# Argument 1 - role (optional)
+#	   2 - types
+#
+define(`role_opt_types',`ifelse(`$1',`',`',`role $1 types $2;')')
+
+##############################
+#
+# Optional typeattribute  handling
+# Argument 1 - attribute
+#	   2 - types (optional)
+#
+define(`attribute_types_opt',`ifelse(`$2',`',`',`typeattribute $1 $2;')')
+
+##############################
+#
+# Declarations for inherited resources
+# Argument 1 - prefix
+#
+define(`decl_inh_resources',`
+attribute $1_inherited_fd;
+attribute $1_inherited_pipe;
+attribute $1_inherited_file;
+attribute $1_inherited_terminal;
+')
+
+##############################
+#
+# Rules for inherited resources
+# Argument 1 - domain to control access
+#	   2 - prefix
+#
+define(`rules_inh_resources',`
+allow $1 $2_inherited_fd:fd use;
+allow $1 $2_inherited_pipe:fifo_file rw_fifo_file_perms;
+allow $1 $2_inherited_file:file rw_file_perms;
+allow $1 $2_inherited_terminal:chr_file rw_term_perms;
+')
Index: policy/modules/admin/rpm.if
===================================================================
--- policy/modules/admin/rpm.if.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/admin/rpm.if	2008-04-22 16:00:22.000000000 +0200
@@ -71,7 +71,7 @@
 	rpm_domtrans($1)
 	role $2 types rpm_t;
 	role $2 types rpm_script_t;
-	seutil_run_loadpolicy(rpm_script_t,$2,$3)
+	seutil_run_loadpolicy(rpm_script_t,$2,,,,$3)
 	seutil_run_semanage(rpm_script_t,$2,$3)
 	seutil_run_setfiles(rpm_script_t,$2,$3)
 	allow rpm_t $3:chr_file rw_term_perms;
Index: policy/modules/system/selinuxutil.if
===================================================================
--- policy/modules/system/selinuxutil.if.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/system/selinuxutil.if	2008-04-22 16:18:05.000000000 +0200
@@ -36,9 +36,24 @@
 ##	The role to be allowed the checkpolicy domain.
 ##	</summary>
 ## </param>
-## <param name="terminal">
+## <param name="fds">
+##	<summary>
+##	Types of fds to allow the checkpolicy domain to use.
+##	</summary>
+## </param>
+## <param name="pipes">
+##	<summary>
+##	Types of pipes to allow the checkpolicy domain to use.
+##	</summary>
+## </param>
+## <param name="files">
+##	<summary>
+##	Types of files to allow the checkpolicy domain to use.
+##	</summary>
+## </param>
+## <param name="terminals">
 ##	<summary>
-##	The type of the terminal allow the checkpolicy domain to use.
+##	Types of terminals to allow the checkpolicy domain to use.
 ##	</summary>
 ## </param>
 ## <rolecap/>
@@ -46,11 +61,16 @@
 interface(`seutil_run_checkpolicy',`
 	gen_require(`
 		type checkpolicy_t;
+		decl_inh_resources(checkpolicy)
+		decl_inh_resources(loadpolicy)
 	')
 
 	seutil_domtrans_checkpolicy($1)
-	role $2 types checkpolicy_t;
-	allow checkpolicy_t $3:chr_file rw_term_perms;
+	role_opt_types(`$2', checkpolicy_t)
+	attribute_types_opt(checkpolicy_inherited_fd, `$3')
+	attribute_types_opt(checkpolicy_inherited_pipe, `$4')
+	attribute_types_opt(checkpolicy_inherited_file, `$5')
+	attribute_types_opt(checkpolicy_inherited_terminal, `$6')
 ')
 
 ########################################
@@ -109,9 +129,24 @@
 ##	The role to be allowed the load_policy domain.
 ##	</summary>
 ## </param>
-## <param name="terminal">
+## <param name="fds">
+##	<summary>
+##	Types of fds to allow the load_policy domain to use.
+##	</summary>
+## </param>
+## <param name="pipes">
+##	<summary>
+##	Types of pipes to allow the load_policy domain to use.
+##	</summary>
+## </param>
+## <param name="files">
+##	<summary>
+##	Types of files to allow the load_policy domain to use.
+##	</summary>
+## </param>
+## <param name="terminals">
 ##	<summary>
-##	The type of the terminal allow the load_policy domain to use.
+##	Types of terminals to allow the load_policy domain to use.
 ##	</summary>
 ## </param>
 ## <rolecap/>
@@ -122,8 +157,11 @@
 	')
 
 	seutil_domtrans_loadpolicy($1)
-	role $2 types load_policy_t;
-	allow load_policy_t $3:chr_file rw_term_perms;
+	role_opt_types(`$2', load_policy_t)
+	attribute_types_opt(loadpolicy_inherited_fd, `$3')
+	attribute_types_opt(loadpolicy_inherited_pipe, `$4')
+	attribute_types_opt(loadpolicy_inherited_file, `$5')
+	attribute_types_opt(loadpolicy_inherited_terminal, `$6')
 ')
 
 ########################################
Index: policy/modules/system/selinuxutil.te
===================================================================
--- policy/modules/system/selinuxutil.te.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/system/selinuxutil.te	2008-04-22 16:00:22.000000000 +0200
@@ -109,6 +109,10 @@
 init_system_domain(setfiles_t,setfiles_exec_t)
 domain_obj_id_change_exemption(setfiles_t)
 
+# declarations for inherited resources
+decl_inh_resources(checkpolicy)
+decl_inh_resources(loadpolicy)
+
 ########################################
 #
 # Checkpolicy local policy
@@ -151,6 +155,9 @@
 	')
 ')
 
+# allow access to inherited resources
+rules_inh_resources(checkpolicy_t, checkpolicy)
+
 ########################################
 #
 # Load_policy local policy
@@ -204,6 +211,9 @@
 	')
 ')
 
+# allow access to inherited resources
+rules_inh_resources(load_policy_t, loadpolicy)
+
 ########################################
 #
 # Newrole local policy
Index: policy/modules/system/userdomain.if
===================================================================
--- policy/modules/system/userdomain.if.orig	2008-04-22 16:00:07.000000000 +0200
+++ policy/modules/system/userdomain.if	2008-04-22 16:00:22.000000000 +0200
@@ -1446,8 +1446,8 @@
 	logging_read_audit_config($1)
 
 	seutil_manage_bin_policy($1)
-	seutil_run_checkpolicy($1,$2,$3)
-	seutil_run_loadpolicy($1,$2,$3)
+	seutil_run_checkpolicy($1,$2,,,,$3)
+	seutil_run_loadpolicy($1,$2,,,,$3)
 	seutil_run_semanage($1,$2,$3)
 	seutil_run_setfiles($1, $2, $3)
 

Re: refpolicy: domains need access to the apt's pty and fifos

[Václav Ovsík]

On Wed, Apr 23, 2008 at 12:30:42PM +0200, Václav Ovsík wrote:
...
> Thanks for the exhaustive explanation Christopher. It seemed to me, that
> your idea can be done at least for types (a roleattribute keyword not
> exist yet), but I was wrong about attributes :(. Attribute can't have
> attribute (recursively). With an attached nonfunctional patch I ended
> with:
> 
> /usr/bin/checkmodule -M -m tmp/apt.tmp -o tmp/apt.mod
> /usr/bin/checkmodule:  loading policy configuration from tmp/apt.tmp
> policy/modules/admin/apt.te":135:ERROR 'unknown type dpkg_inherited_fd' at token ';' on line 7686:
>         typeattribute dpkg_inherited_fd apt_inherited_fd;
> #line 135
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> make: *** [tmp/apt.mod] Error 1
> 
> Of course dpkg_inherited_fd is the attribute and not the type, shame.
> You are right, with current policy language this can't be done easily.
> 
> Maybe wee can do this job using m4. This would require an additional
> pass to process sources or modification of processing a bit. My rough
> idea for modular policy:
>     * To include the third new parameter of interface/template macro
>       used by run interfaces. This parameter will accept what and how
>       should be inherited in some notation parse able fine by m4. The
>       information "what" should describe the class (fd, pipe...), the
>       type. The information "how" should describe passing down (to pass
>       inheritance down or to stop inheritance there).
>     * To split module preprocessing (m4) and compilation (checkmodule)
>       (Rules.modular).
>     * All modules must by m4 processed at first to create the
>       meta-information about all inheritances. The compilation
>       (checkmodule) of any module (with some run interface) should
>       depend on meta-information from all other packages.
>     * Updating of inheritance meta-information must be updated only when
>       the content is really different, so Make will not restart
>       rebuilding things unnecessarily.
>     * To build allow rules from inheritance meta-information and append
>       this rules to already preprocessed .te product and compile it by
>       checkmodule.
...

I see at least one flaw - the policy build in such a way will be
somewhat "static" concerning adding modules into pre-build policy. That
is when someone will take policy headers and compile an own local
module, then all other pre-build modules affected by inheritance will be
obsolete. So, there is no improvement in this area against current
state.

The only benefit from the proposal is, that policy sources will be a bit
more clean (I hope) and ready for introducing inheritance in the policy
language (I hope only macros and processing will need change).

Best Regards
-- 
Zito

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy: domains need access to the apt's pty and fifos

[Christopher J. PeBenito]

On Thu, 2008-04-24 at 10:42 +0200, Václav Ovsík wrote:
> On Wed, Apr 23, 2008 at 12:30:42PM +0200, Václav Ovsík wrote:
> ...
> > Thanks for the exhaustive explanation Christopher. It seemed to me, that
> > your idea can be done at least for types (a roleattribute keyword not
> > exist yet), but I was wrong about attributes :(. Attribute can't have
> > attribute (recursively). With an attached nonfunctional patch I ended
> > with:
> > 
> > /usr/bin/checkmodule -M -m tmp/apt.tmp -o tmp/apt.mod
> > /usr/bin/checkmodule:  loading policy configuration from tmp/apt.tmp
> > policy/modules/admin/apt.te":135:ERROR 'unknown type dpkg_inherited_fd' at token ';' on line 7686:
> >         typeattribute dpkg_inherited_fd apt_inherited_fd;
> > #line 135
> > /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> > make: *** [tmp/apt.mod] Error 1
> > 
> > Of course dpkg_inherited_fd is the attribute and not the type, shame.
> > You are right, with current policy language this can't be done easily.
> > 
> > Maybe wee can do this job using m4. This would require an additional
> > pass to process sources or modification of processing a bit. My rough
> > idea for modular policy:
> >     * To include the third new parameter of interface/template macro
> >       used by run interfaces. This parameter will accept what and how
> >       should be inherited in some notation parse able fine by m4. The
> >       information "what" should describe the class (fd, pipe...), the
> >       type. The information "how" should describe passing down (to pass
> >       inheritance down or to stop inheritance there).
> >     * To split module preprocessing (m4) and compilation (checkmodule)
> >       (Rules.modular).
> >     * All modules must by m4 processed at first to create the
> >       meta-information about all inheritances. The compilation
> >       (checkmodule) of any module (with some run interface) should
> >       depend on meta-information from all other packages.
> >     * Updating of inheritance meta-information must be updated only when
> >       the content is really different, so Make will not restart
> >       rebuilding things unnecessarily.
> >     * To build allow rules from inheritance meta-information and append
> >       this rules to already preprocessed .te product and compile it by
> >       checkmodule.

The problem is that we'd actually like to implement interfaces in the
regular policy language, so m4 won't be processing interfaces in this
way anymore.  There are also many people that want to reduce, rather
than increase, m4 usage :)

> I see at least one flaw - the policy build in such a way will be
> somewhat "static" concerning adding modules into pre-build policy. That
> is when someone will take policy headers and compile an own local
> module, then all other pre-build modules affected by inheritance will be
> obsolete. So, there is no improvement in this area against current
> state.

Interfaces being expanded during compilation resulting in a static
policy is a general issue.  Interfaces in the language would fix that
part since interfaces wouldn't be expanded until linking.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.