[patch] screen_macros.te

[patch] screen_macros.te

[Greg Norris]

[-- Attachment #1.1: Type: text/plain, Size: 140 bytes --]

One of the entries had the parameters backward, which prevented screen
from HUPing it's parent.  This was causing "power detach" to fail.

[-- Attachment #1.2: screen_macros.te.diff --]
[-- Type: text/plain, Size: 472 bytes --]

--- screen_macros.te.orig	2004-12-11 00:13:45.000000000 -0600
+++ screen_macros.te	2005-01-04 16:36:10.000000000 -0600
@@ -76,7 +76,7 @@
 file_type_auto_trans($1_screen_t, screen_dir_t, $1_screen_var_run_t, fifo_file)
 
 allow $1_screen_t self:process { fork signal_perms };
-allow $1_t $1_screen_t:process signal;
+allow $1_screen_t $1_t:process signal;
 allow $1_screen_t self:capability { setuid setgid fsetid };
 
 dontaudit $1_screen_t shadow_t:file read;

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] screen_macros.te

[Greg Norris]

[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]

On Tue, Jan 04, 2005 at 05:01:49PM -0600, Greg Norris wrote:
> One of the entries had the parameters backward, which prevented screen
> from HUPing it's parent.  This was causing "power detach" to fail.

After further testing, it seems that screen actually requires both 
variations.  Here's an updated patch... please disregard my original 
version.

[-- Attachment #1.2: screen_macros.te.diff --]
[-- Type: text/plain, Size: 390 bytes --]

--- screen_macros.te.orig	2004-12-11 00:13:45.000000000 -0600
+++ screen_macros.te	2005-01-04 17:31:01.000000000 -0600
@@ -77,6 +77,7 @@
 
 allow $1_screen_t self:process { fork signal_perms };
 allow $1_t $1_screen_t:process signal;
+allow $1_screen_t $1_t:process signal;
 allow $1_screen_t self:capability { setuid setgid fsetid };
 
 dontaudit $1_screen_t shadow_t:file read;

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] screen_macros.te

[Daniel J Walsh]

I would like to add a new file type cert_t for ssl cert files, since 
these are defaulted to usr_t right now.
Shouldn't these be protected at a higher level?

#
# cert_t is the type of files in the system certs directories.
#
type cert_t, file_type, sysadmfile;

...

/usr/share/ssl/certs(/.*)?              system_u:object_r:cert_t


--
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.

New type cert_t?

[Daniel J Walsh]

Sorry hit reply instead of new.

> I would like to add a new file type cert_t for ssl cert files, since 
> these are defaulted to usr_t right now.
> Shouldn't these be protected at a higher level?
>
> #
> # cert_t is the type of files in the system certs directories.
> #
> type cert_t, file_type, sysadmfile;
>
> ...
>
> /usr/share/ssl/certs(/.*)?              system_u:object_r:cert_t
>
>
> -- 
> 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.



--
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: [patch] screen_macros.te

[Russell Coker]

On Thursday 06 January 2005 00:21, Daniel J Walsh <dwalsh@redhat.com> wrote:
> I would like to add a new file type cert_t for ssl cert files, since
> these are defaulted to usr_t right now.
> Shouldn't these be protected at a higher level?

Are you talking about protecting the integrity or the secrecy of data in such 
files?

If integrity then anything which can write to usr_t can break the system 
anyway.  If secrecy then nothing in an rpm is secret anyway.

If there are certificates that have any secret data then they should be 
somewhere other than under /usr.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: [patch] screen_macros.te

[Daniel J Walsh]

Russell Coker wrote:

>On Thursday 06 January 2005 00:21, Daniel J Walsh <dwalsh@redhat.com> wrote:
>  
>
>>I would like to add a new file type cert_t for ssl cert files, since
>>these are defaulted to usr_t right now.
>>Shouldn't these be protected at a higher level?
>>    
>>
>
>Are you talking about protecting the integrity or the secrecy of data in such 
>files?
>
>If integrity then anything which can write to usr_t can break the system 
>anyway.  If secrecy then nothing in an rpm is secret anyway.
>
>If there are certificates that have any secret data then they should be 
>somewhere other than under /usr.
>
>  
>
They are not in an RPM, and there has been discussions that they should 
be moved under /var/ or /etc/.
I think readability is the problem here.  Wherever they end up we need a 
general case protecting the
certificates so ever application that can read /usr or /etc/ or /var can 
not read these files.   We are also going
have to start looking at how we can protect Kerberos Key Files.  But 
that is another conversation.



--
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: [patch] screen_macros.te

[James Carter]

Merged.

On Tue, 2005-01-04 at 18:34, Greg Norris wrote:
> On Tue, Jan 04, 2005 at 05:01:49PM -0600, Greg Norris wrote:
> > One of the entries had the parameters backward, which prevented screen
> > from HUPing it's parent.  This was causing "power detach" to fail.
> 
> After further testing, it seems that screen actually requires both 
> variations.  Here's an updated patch... please disregard my original 
> version.
-- 
James Carter <jwcart2@epoch.ncsc.mil>
National Security Agency

--
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.