File Browsing apps and getattr

File Browsing apps and getattr

[Ivan Gyurdiev]

What are your thoughts on this bug?
It asks whether it would be reasonable to grant full getattr privileges
to all file browsing applications (like nautilus, mozilla, things with a
file open dialog..)

This has bothered me ever since I first tried selinux - I open up 
nautilus or any other app with a file browser, and soon I get a storm of
denials. There should be a way to fix this.

https://bugzilla.redhat.com/beta/show_bug.cgi?id=146557

The bug says dontaudit, but when dwalsh explained the difference
I see I mean allow instead. 

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Stephen Smalley]

On Mon, 2005-01-31 at 17:26, Ivan Gyurdiev wrote:
> What are your thoughts on this bug?
> It asks whether it would be reasonable to grant full getattr privileges
> to all file browsing applications (like nautilus, mozilla, things with a
> file open dialog..)
> 
> This has bothered me ever since I first tried selinux - I open up 
> nautilus or any other app with a file browser, and soon I get a storm of
> denials. There should be a way to fix this.
> 
> https://bugzilla.redhat.com/beta/show_bug.cgi?id=146557
> 
> The bug says dontaudit, but when dwalsh explained the difference
> I see I mean allow instead.

Allowing access to file_type would obviously be too wide.  Allowing a
user's browser or similar user apps to stat his home directory files
with the corresponding derived types may be reasonable.  The
$1_file_type attribute may help you there.

-- 
Stephen Smalley <sds@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.

Re: File Browsing apps and getattr

[Ivan Gyurdiev]

On Tue, 2005-02-01 at 07:11 -0500, Stephen Smalley wrote:
> On Mon, 2005-01-31 at 17:26, Ivan Gyurdiev wrote:
> > What are your thoughts on this bug?
> > It asks whether it would be reasonable to grant full getattr privileges
> > to all file browsing applications (like nautilus, mozilla, things with a
> > file open dialog..)
> > 
> > This has bothered me ever since I first tried selinux - I open up 
> > nautilus or any other app with a file browser, and soon I get a storm of
> > denials. There should be a way to fix this.
> > 
> > https://bugzilla.redhat.com/beta/show_bug.cgi?id=146557
> > 
> > The bug says dontaudit, but when dwalsh explained the difference
> > I see I mean allow instead.
> 
> Allowing access to file_type would obviously be too wide.  

Why? I don't see why it's necessary to get all those denials,
and why ls doesn't show me the file properties for restricted types. 
It seems reasonable to me that if you can search the parent directory
you should be permitted to stat the files in it.

Even the manpage of stat() says so:

"These  functions  return information about the specified file.  You do
not need any access rights to the file to get this information but you
need search rights to all directories named in the path leading to the
file."

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Stephen Smalley]

On Tue, 2005-02-01 at 08:08, Ivan Gyurdiev wrote:
> Why? I don't see why it's necessary to get all those denials,
> and why ls doesn't show me the file properties for restricted types. 
> It seems reasonable to me that if you can search the parent directory
> you should be permitted to stat the files in it.
> 
> Even the manpage of stat() says so:
> 
> "These  functions  return information about the specified file.  You do
> not need any access rights to the file to get this information but you
> need search rights to all directories named in the path leading to the
> file."

Yes, that is in the absence of mandatory access control.  Properties of
the file should be protected in accordance with the security label of
the file, not the parent directory.  The name is part of the directory
state, but the stat(2) information is part of the inode state.

-- 
Stephen Smalley <sds@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.

Re: File Browsing apps and getattr

[Ivan Gyurdiev]

> > "These  functions  return information about the specified file.  You do
> > not need any access rights to the file to get this information but you
> > need search rights to all directories named in the path leading to the
> > file."
> 
> Yes, that is in the absence of mandatory access control.  Properties of
> the file should be protected in accordance with the security label of
> the file, not the parent directory.  The name is part of the directory
> state, but the stat(2) information is part of the inode state.

Why is the stat() information so important for security?
If you won't do this, how do you plan to address the denials I have
posted about? 

Will you leave ls in this state:

[phantom@cobra ~]$ ls -l /var
total 112
?---------   ? ?    ?       ?            ? account
drwxr-xr-x  10 root root 4096 Jan 16 05:33 cache
drwxr-xr-x   3 root root 4096 Oct 19 13:20 db
drwxr-xr-x   3 root root 4096 Aug 12 11:02 empty
?---------   ? ?    ?       ?            ? gdm
drwxr-xr-x  24 root root 4096 Jan 16 05:33 lib
drwxr-xr-x   2 root root 4096 Aug 12 11:02 local
?---------   ? ?    ?       ?            ? lock
drwxr-xr-x  13 root root 4096 Feb  1 04:02 log
?---------   ? ?    ?       ?            ? mail
?---------   ? ?    ?       ?            ? named
drwx------   2 root root 4096 Dec  1 13:49 net-snmp
drwxr-xr-x   2 root root 4096 Aug 12 11:02 nis
drwxr-xr-x   2 root root 4096 Aug 12 11:02 opt
drwxr-xr-x   2 root root 4096 Aug 12 11:02 preserve
drwxr-xr-x  18 root root 4096 Feb  1 06:16 run
drwxr-xr-x  14 root root 4096 Aug 12 11:02 spool
drwxrwxrwt   2 root root 4096 Feb  1 06:16 tmp
drwxr-xr-x  12 root root 4096 Jan 11 19:28 www
?---------   ? ?    ?       ?            ? yp
[phantom@cobra ~]$

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Stephen Smalley]

On Tue, 2005-02-01 at 08:26, Ivan Gyurdiev wrote:
> Why is the stat() information so important for security?

It depends on the particular file, obviously.  The point is that it
represents an information flow that conveys possibly sensitive
information about the object, and should be controlled in accordance
with the security properties of the object.

> If you won't do this, how do you plan to address the denials I have
> posted about? 
> 
> Will you leave ls in this state:
> 
> [phantom@cobra ~]$ ls -l /var
> total 112
> ?---------   ? ?    ?       ?            ? account
> drwxr-xr-x  10 root root 4096 Jan 16 05:33 cache
> drwxr-xr-x   3 root root 4096 Oct 19 13:20 db
> drwxr-xr-x   3 root root 4096 Aug 12 11:02 empty
> ?---------   ? ?    ?       ?            ? gdm
> drwxr-xr-x  24 root root 4096 Jan 16 05:33 lib
> drwxr-xr-x   2 root root 4096 Aug 12 11:02 local
> ?---------   ? ?    ?       ?            ? lock
> drwxr-xr-x  13 root root 4096 Feb  1 04:02 log
> ?---------   ? ?    ?       ?            ? mail
> ?---------   ? ?    ?       ?            ? named
> drwx------   2 root root 4096 Dec  1 13:49 net-snmp
> drwxr-xr-x   2 root root 4096 Aug 12 11:02 nis
> drwxr-xr-x   2 root root 4096 Aug 12 11:02 opt
> drwxr-xr-x   2 root root 4096 Aug 12 11:02 preserve
> drwxr-xr-x  18 root root 4096 Feb  1 06:16 run
> drwxr-xr-x  14 root root 4096 Aug 12 11:02 spool
> drwxrwxrwt   2 root root 4096 Feb  1 06:16 tmp
> drwxr-xr-x  12 root root 4096 Jan 11 19:28 www
> ?---------   ? ?    ?       ?            ? yp
> [phantom@cobra ~]$

You can certainly propose allowing access to additional file types on a
case-by-case basis, possibly introducing new attributes to identify the
desired set of types, but adding permissions always requires a
justification, not just 'why not?'.  What is the functional requirement
that ls display the attributes of those subdirectories/files?  What is
the real benefit if you cannot search the subdirectories or read the
files?

dontaudit is appropriate if you just want to silence the warnings,
although you obviously don't want to do that for a file to which you
truly want to track attempted accesses.

-- 
Stephen Smalley <sds@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.

Re: File Browsing apps and getattr

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2005-02-01 at 08:26, Ivan Gyurdiev wrote:
>  
>
>>Why is the stat() information so important for security?
>>    
>>
>
>It depends on the particular file, obviously.  The point is that it
>represents an information flow that conveys possibly sensitive
>information about the object, and should be controlled in accordance
>with the security properties of the object.
>
>  
>
>>If you won't do this, how do you plan to address the denials I have
>>posted about? 
>>
>>Will you leave ls in this state:
>>
>>[phantom@cobra ~]$ ls -l /var
>>total 112
>>?---------   ? ?    ?       ?            ? account
>>drwxr-xr-x  10 root root 4096 Jan 16 05:33 cache
>>drwxr-xr-x   3 root root 4096 Oct 19 13:20 db
>>drwxr-xr-x   3 root root 4096 Aug 12 11:02 empty
>>?---------   ? ?    ?       ?            ? gdm
>>drwxr-xr-x  24 root root 4096 Jan 16 05:33 lib
>>drwxr-xr-x   2 root root 4096 Aug 12 11:02 local
>>?---------   ? ?    ?       ?            ? lock
>>drwxr-xr-x  13 root root 4096 Feb  1 04:02 log
>>?---------   ? ?    ?       ?            ? mail
>>?---------   ? ?    ?       ?            ? named
>>drwx------   2 root root 4096 Dec  1 13:49 net-snmp
>>drwxr-xr-x   2 root root 4096 Aug 12 11:02 nis
>>drwxr-xr-x   2 root root 4096 Aug 12 11:02 opt
>>drwxr-xr-x   2 root root 4096 Aug 12 11:02 preserve
>>drwxr-xr-x  18 root root 4096 Feb  1 06:16 run
>>drwxr-xr-x  14 root root 4096 Aug 12 11:02 spool
>>drwxrwxrwt   2 root root 4096 Feb  1 06:16 tmp
>>drwxr-xr-x  12 root root 4096 Jan 11 19:28 www
>>?---------   ? ?    ?       ?            ? yp
>>[phantom@cobra ~]$
>>    
>>
>
>You can certainly propose allowing access to additional file types on a
>case-by-case basis, possibly introducing new attributes to identify the
>desired set of types, but adding permissions always requires a
>justification, not just 'why not?'.  What is the functional requirement
>that ls display the attributes of those subdirectories/files?  What is
>the real benefit if you cannot search the subdirectories or read the
>files?
>
>dontaudit is appropriate if you just want to silence the warnings,
>although you obviously don't want to do that for a file to which you
>truly want to track attempted accesses.
>
>  
>
There is already a usrcanread attribute.

Should we create another attribute SECURITYFILE, so we could label 
file_types that have greater security concerns.

shadow_t, cert_t, kerberos_*, ...




--
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: File Browsing apps and getattr

[Ivan Gyurdiev]

> You can certainly propose allowing access to additional file types on a
> case-by-case basis, possibly introducing new attributes to identify the
> desired set of types, but adding permissions always requires a
> justification, not just 'why not?'.  What is the functional requirement
> that ls display the attributes of those subdirectories/files?  What is
> the real benefit if you cannot search the subdirectories or read the
> files?

I've accepted that searching the subdirectories and reading the files
is something we do not want to/need to do. I was just asking about the
getattr check. 

I understand your arguments, however, and will agree this is not
absolutely necessary. What needs to be done in that case is dontaudit,
so that those denials go away.

> dontaudit is appropriate if you just want to silence the warnings,
> although you obviously don't want to do that for a file to which you
> truly want to track attempted accesses.

Would it be acceptable to have dontaudit getattr on dir_file_class_set
for file browsing applications. I currently have a rule like that in the
mplayer policy? If not, how would you suggest the denials be suppressed?

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Stephen Smalley]

On Tue, 2005-02-01 at 13:42, Ivan Gyurdiev wrote:
> Would it be acceptable to have dontaudit getattr on dir_file_class_set
> for file browsing applications. I currently have a rule like that in the
> mplayer policy? If not, how would you suggest the denials be suppressed?

I think we want to avoid suppressing the audit for all file types, i.e.
not use file_type by itself.  Possibly a file_type - security_type as
per Dan's suggestion.  Also, we may be able to legitimately add
permission for some of these types, possibly adding usercanread to them,
but it just requires a case-by-case review.

-- 
Stephen Smalley <sds@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.

Re: File Browsing apps and getattr

[Ivan Gyurdiev]

On Tue, 2005-02-01 at 14:52 -0500, Stephen Smalley wrote:
> On Tue, 2005-02-01 at 13:42, Ivan Gyurdiev wrote:
> > Would it be acceptable to have dontaudit getattr on dir_file_class_set
> > for file browsing applications. I currently have a rule like that in the
> > mplayer policy? If not, how would you suggest the denials be suppressed?
> 
> I think we want to avoid suppressing the audit for all file types, i.e.
> not use file_type by itself.  Possibly a file_type - security_type as
> per Dan's suggestion.  Also, we may be able to legitimately add
> permission for some of these types, possibly adding usercanread to them,
> but it just requires a case-by-case review.

But the audit message can be triggered by legitimate usage (ls -l /etc,
ls -l /var). It doesn't make sense to me to log legitimate usage of a
program as an error. 

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Stephen Smalley]

On Tue, 2005-02-01 at 18:39, Ivan Gyurdiev wrote:
> On Tue, 2005-02-01 at 14:52 -0500, Stephen Smalley wrote:
> > On Tue, 2005-02-01 at 13:42, Ivan Gyurdiev wrote:
> > > Would it be acceptable to have dontaudit getattr on dir_file_class_set
> > > for file browsing applications. I currently have a rule like that in the
> > > mplayer policy? If not, how would you suggest the denials be suppressed?
> > 
> > I think we want to avoid suppressing the audit for all file types, i.e.
> > not use file_type by itself.  Possibly a file_type - security_type as
> > per Dan's suggestion.  Also, we may be able to legitimately add
> > permission for some of these types, possibly adding usercanread to them,
> > but it just requires a case-by-case review.
> 
> But the audit message can be triggered by legitimate usage (ls -l /etc,
> ls -l /var). It doesn't make sense to me to log legitimate usage of a
> program as an error. 

etc_t and var_t are unlikely to fall under "security_type", so file_type
- security_type would cover them.

-- 
Stephen Smalley <sds@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.

Re: File Browsing apps and getattr

[Ivan Gyurdiev]

On Wed, 2005-02-02 at 07:03 -0500, Stephen Smalley wrote:
> On Tue, 2005-02-01 at 18:39, Ivan Gyurdiev wrote:
> > On Tue, 2005-02-01 at 14:52 -0500, Stephen Smalley wrote:
> > > On Tue, 2005-02-01 at 13:42, Ivan Gyurdiev wrote:
> > > > Would it be acceptable to have dontaudit getattr on dir_file_class_set
> > > > for file browsing applications. I currently have a rule like that in the
> > > > mplayer policy? If not, how would you suggest the denials be suppressed?
> > > 
> > > I think we want to avoid suppressing the audit for all file types, i.e.
> > > not use file_type by itself.  Possibly a file_type - security_type as
> > > per Dan's suggestion.  Also, we may be able to legitimately add
> > > permission for some of these types, possibly adding usercanread to them,
> > > but it just requires a case-by-case review.
> > 
> > But the audit message can be triggered by legitimate usage (ls -l /etc,
> > ls -l /var). It doesn't make sense to me to log legitimate usage of a
> > program as an error. 
> 
> etc_t and var_t are unlikely to fall under "security_type", so file_type
> - security_type would cover them.

It was a general question, regardless of the specific type. 
I thought perhaps shadow_t would be a security type, and would produce
denials when I do ls -l /etc. What would you consider a
security type?

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Stephen Smalley]

On Wed, 2005-02-02 at 08:19, Ivan Gyurdiev wrote:
> It was a general question, regardless of the specific type. 
> I thought perhaps shadow_t would be a security type, and would produce
> denials when I do ls -l /etc. What would you consider a
> security type?

Yes, shadow_t would fall into that class.  So at that point you might
dontaudit attempts to getattr it from user domains, while leaving them
audited for the daemon domains.

-- 
Stephen Smalley <sds@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.

Re: File Browsing apps and getattr

[Ivan Gyurdiev]

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

On Wed, 2005-02-02 at 08:14 -0500, Stephen Smalley wrote:
> On Wed, 2005-02-02 at 08:19, Ivan Gyurdiev wrote:
> > It was a general question, regardless of the specific type. 
> > I thought perhaps shadow_t would be a security type, and would produce
> > denials when I do ls -l /etc. What would you consider a
> > security type?
> 
> Yes, shadow_t would fall into that class.  So at that point you might
> dontaudit attempts to getattr it from user domains, while leaving them
> audited for the daemon domains.

Patch for user_macros.te and samba_macros.te attached.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University

[-- Attachment #2: samba.patch --]
[-- Type: text/x-patch, Size: 335 bytes --]

--- samba_macros.te	2005-02-02 07:05:30.000000000 -0700
+++ samba_macros.new	2005-02-02 07:05:14.000000000 -0700
@@ -21,6 +21,7 @@
 if ( samba_enable_home_dirs ) {
 allow smbd_t home_root_t:dir r_dir_perms;
 file_type_auto_trans(smbd_t, $1_home_dir_t, $1_home_t)
+dontaudit smbd_t $1_file_type:dir_file_class_set getattr;
 }
 ')
 ', `

[-- Attachment #3: user.patch --]
[-- Type: text/x-patch, Size: 631 bytes --]

--- user_macros.te	2005-02-02 07:07:32.000000000 -0700
+++ user_macros.new	2005-02-02 07:08:00.000000000 -0700
@@ -93,8 +93,8 @@
 # Do not audit write denials to utmp to avoid the noise.
 dontaudit $1_t initrc_var_run_t:file write;
 
-# do not audit getattr on tmpfile, otherwise ls -l /tmp fills the logs
-dontaudit $1_t tmpfile:dir_file_class_set getattr;
+# do not audit getattr on dir/files to prevent ls -l denials
+dontaudit $1_t file_type:dir_file_class_set getattr; 
 
 # do not audit getattr on disk devices, otherwise KDE fills the logs
 dontaudit $1_t { removable_device_t fixed_disk_device_t }:blk_file {getattr read};

Re: File Browsing apps and getattr

[Daniel J Walsh]

Added file_browse_domain to latest policy

define(`file_browse_domain', `
# Do not flood message log, if the user does a browse
allow $1 file_type - secure_file_type:file getattr;
dontaudit $1 dev_fs:dir_file_class_set getattr;
dontaudit $1 sysadmfile:file getattr;
dontaudit $1 sysadmfile:dir read;
')dnl end file_browse_domain

Added to base_user_domain, mozilla and mplayer.
Also added secure_file_type attribute, to shadow_t, kerberos_keytab_t, 
and cert_t.

I will submit a policy patch later.



--
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: File Browsing apps and getattr

[Stephen Smalley]

On Wed, 2005-02-02 at 09:07, Daniel J Walsh wrote:
> Added file_browse_domain to latest policy
> 
> define(`file_browse_domain', `
> # Do not flood message log, if the user does a browse
> allow $1 file_type - secure_file_type:file getattr;
> dontaudit $1 dev_fs:dir_file_class_set getattr;
> dontaudit $1 sysadmfile:file getattr;
> dontaudit $1 sysadmfile:dir read;
> ')dnl end file_browse_domain

Not clear why you want the dontaudit rules for sysadmfile, and it seems
like there would be a lot of overlap between the dontaudit getattr rule
and the allow getattr rule, meaning that you are wasting an access
vector in most cases.  

-- 
Stephen Smalley <sds@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.

Re: File Browsing apps and getattr

[Daniel J Walsh]

Stephen Smalley wrote:

>On Wed, 2005-02-02 at 09:07, Daniel J Walsh wrote:
>  
>
>>Added file_browse_domain to latest policy
>>
>>define(`file_browse_domain', `
>># Do not flood message log, if the user does a browse
>>allow $1 file_type - secure_file_type:file getattr;
>>dontaudit $1 dev_fs:dir_file_class_set getattr;
>>dontaudit $1 sysadmfile:file getattr;
>>dontaudit $1 sysadmfile:dir read;
>>')dnl end file_browse_domain
>>    
>>
>
>  
>
Tightened up a little bit.
define(`file_browse_domain', `
# Do not flood message log, if the user does a browse
dontaudit $1 file_type - secure_file_type:dir_file_class_set getattr;
dontaudit $1 dev_fs:dir_file_class_set getattr;
dontaudit $1 file_type - secure_file_type:dir read;
')dnl end file_browse_domain


>Not clear why you want the dontaudit rules for sysadmfile, and it seems
>like there would be a lot of overlap between the dontaudit getattr rule
>and the allow getattr rule, meaning that you are wasting an access
>vector in most cases.  
>
>  
>


--
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: File Browsing apps and getattr

[Ivan Gyurdiev]

> Tightened up a little bit.
> define(`file_browse_domain', `
> # Do not flood message log, if the user does a browse
> dontaudit $1 file_type - secure_file_type:dir_file_class_set getattr;
> dontaudit $1 dev_fs:dir_file_class_set getattr;
> dontaudit $1 file_type - secure_file_type:dir read;
> ')dnl end file_browse_domain

I don't like how security types are being excluded as being special.
I understand the concern, but that will cause audited denials for proper
use of applications like ls. 

Stephen Smalley:
"Yes, shadow_t would fall into that class.  So at that point you might
dontaudit attempts to getattr it from user domains, while leaving them
audited for the daemon domains."

I don't think daemon domains should be using this file_browse_domain
in the first place - seems to me like it should be used only for user
domains. For smbd, for example, something more specialized could be used
like the patch I posted which is restricted to $1_file_type only
(since we don't allow arbitrary samba shares through the filesystem
anyway)

Will user_t be using this macro? 
-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>>Tightened up a little bit.
>>define(`file_browse_domain', `
>># Do not flood message log, if the user does a browse
>>dontaudit $1 file_type - secure_file_type:dir_file_class_set getattr;
>>dontaudit $1 dev_fs:dir_file_class_set getattr;
>>dontaudit $1 file_type - secure_file_type:dir read;
>>')dnl end file_browse_domain
>>    
>>
>
>I don't like how security types are being excluded as being special.
>I understand the concern, but that will cause audited denials for proper
>use of applications like ls. 
>
>  
>
Doing ls of Kerberos keyfiles, certs and shadow or any other security 
file should probably be audited in
a strict policy, because the next thing would be an attempt at a read.  
It might be usefull to know that the
latest mozilla plugin is poking around some more secure files.  
Dontaudit would just cover this up.

>Stephen Smalley:
>"Yes, shadow_t would fall into that class.  So at that point you might
>dontaudit attempts to getattr it from user domains, while leaving them
>audited for the daemon domains."
>
>I don't think daemon domains should be using this file_browse_domain
>in the first place - seems to me like it should be used only for user
>domains. For smbd, for example, something more specialized could be used
>like the patch I posted which is restricted to $1_file_type only
>(since we don't allow arbitrary samba shares through the filesystem
>anyway)
>
>Will user_t be using this macro? 
>  
>
Yes.  There already was similar code in the base_user_macros.te file.

Dan

--
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: File Browsing apps and getattr

[Ivan Gyurdiev]

> Doing ls of Kerberos keyfiles, certs and shadow or any other security 
> file should probably be audited in
> a strict policy, because the next thing would be an attempt at a read. 

Doing ls -l /etc does not imply attempted read of shadow.
Furthermore the read would be audited so I don't see the problem. 
The getattr would be denied, so Stephen Smalley's concern about 
information flow is addressed.

> It might be usefull to know that the
> latest mozilla plugin is poking around some more secure files.  
> Dontaudit would just cover this up.

You're still auditing { read write } on files.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: File Browsing apps and getattr

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:


> Why is the stat() information so important for
> security?

In a mandatory access control environment the
attributes (e.g. inode information) are
considered to be as sensitive as the data.
Why? Because the attributes are manipulated
by processes with the same sensitivity as
the data. A Top Secret file can be manipulated
by a Top Secret user. If an Unclassified user
could read the attributes information could
be overtly passed down using chmod, chown,
utime, link, unlink, acl_set_file, and
truncate.

> If you won't do this, how do you plan to address the
> denials I have
> posted about? 
> 
> Will you leave ls in this state:
> 
> [phantom@cobra ~]$ ls -l /var
> total 112
> ?---------   ? ?    ?       ?            ? account
> drwxr-xr-x  10 root root 4096 Jan 16 05:33 cache

This is exactly what the U2X mandatory access
control systems do. Actually, you'll see ls
spewing "access denied" messages, not the neater
"?" form you have here.

In the U2X world we always had the luxury of
telling irate users that this is exactly the
correct behavior that they had paid extra for.
Cackle.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

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