Re: tmpfs_t

Re: tmpfs_t

[Stephen D. Smalley]

> I have been looking into using tmpfs as /tmp .
> 
> Currently tmpfs is labeled tmpfs_t and there is no policy for allowing file 
> creation under it.  So I have experimented with labelling it as tmp_t and 
> changing the tmp_domain() macro to have the following rule:
> allow $1_tmp_t tmp_t:filesystem associate;
> 
> To do this properly I would also have to change every
> allow whatever fs_t:filesystem getattr;
> to:
> allow whatever { fs_t tmp_t }:filesystem getattr;
> 
> Or should I instead leave the tmpfs filesystem labelled as tmpfs_t and add 
> appropriate file_type_auto_trans() rules for it?

The problem is that tmpfs is also used for the kernel internal mount
for System V shared memory and shared anonymous mappings.  The current
fs_use configuration and the existing $1_tmpfs_t types and rules are
oriented toward that usage of tmpfs.  Distinguishing different instances
of tmpfs mounts and providing different labeling behaviors and contexts
for those different instances would require further changes to SELinux. 

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
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: tmpfs_t

[Russell Coker]

On Mon, 27 Jan 2003 14:20, Stephen D. Smalley wrote:
> The problem is that tmpfs is also used for the kernel internal mount
> for System V shared memory and shared anonymous mappings.  The current
> fs_use configuration and the existing $1_tmpfs_t types and rules are
> oriented toward that usage of tmpfs.  Distinguishing different instances
> of tmpfs mounts and providing different labeling behaviors and contexts
> for those different instances would require further changes to SELinux.

I believe that changes are required.

For UML and busy Apache servers using tmpfs as /tmp is common practise.  The 
current SE Linux setup will force many of the people who run big servers to 
change their operation in a way that will hurt performance to support running 
SE Linux.

I've experimented with using chcon to set the type after mounting which seems 
to work OK.

I believe that the best option is to label the root inode of tmpfs as 
system_u:object_r:tmp_t via initial_sid_contexts.  I've been looking at the 
kernel code, is superblock_doinit() the right place to do a change?

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

SELinux question?

[Daniel J Walsh]

Why are certain applications (ls, cp, cd) ported to use SELinux with the 
standard names, while others
(spasswd, schfn) have a prefix added?  

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: SELinux question?

[Tom]

On Tue, Feb 04, 2003 at 02:58:38AM -0500, Daniel J Walsh wrote:
> Why are certain applications (ls, cp, cd) ported to use SELinux with the 
> standard names, while others
> (spasswd, schfn) have a prefix added?  

ls, ps and others are modified versions of the originals.

spasswd, and the other s* programs are wrappers around the original
tools. For various reasons, this was the only or better way of making
them SE-aware in those cases.



-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: SELinux question?

[Daniel J Walsh]

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

Tom wrote:

>On Tue, Feb 04, 2003 at 02:58:38AM -0500, Daniel J Walsh wrote:
>  
>
>>Why are certain applications (ls, cp, cd) ported to use SELinux with the 
>>standard names, while others
>>(spasswd, schfn) have a prefix added?  
>>    
>>
>
>ls, ps and others are modified versions of the originals.
>
>spasswd, and the other s* programs are wrappers around the original
>tools. For various reasons, this was the only or better way of making
>them SE-aware in those cases.
>
>
>
>  
>
So they did it because it was easier to wrap the application then to 
change the code, correct?
In the other cases they could not wrap the apps so they went in and 
changed the code.  
I would like to know if there was any other reason to use the s* syntax, 
or all things being equil
you would replace the passwd command with a SELinux aware passwd command?

Dan

Dan

[-- Attachment #2: Type: text/html, Size: 1191 bytes --]

Re: SELinux question?

[Russell Coker]

On Tue, 4 Feb 2003 16:49, Daniel J Walsh wrote:
> So they did it because it was easier to wrap the application then to
> change the code, correct?

Yes.  Changing the application requires keeping up to date with new versions 
of the application (on-going work) and also it's easy to make a mistake when 
working with someone else's uncommented code.

For some things it's necessary, EG changing the login programs and cron 
because the change is so tightly related to the task.  For some things it 
doesn't make sense to try and wrap it (EG ls).

For some programs such as passwd it's not something you want to get into 
yourself, it's easiest to write a wrapper, and there are a family of programs 
which can all be serviced by the same wrapper if done properly.

> I would like to know if there was any other reason to use the s* syntax,
> or all things being equil
> you would replace the passwd command with a SELinux aware passwd command?

The spasswd program is hard-coded to run /usr/bin/passwd, so if you rename it 
then you'll also have to change the code.

I could do such things quite easily for my Debian packaging of SE Linux 
programs, but the NSA are focusing on a tarball release which makes such 
things impractically difficult.

-- 
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: SELinux question?

[Frank Mayer]

> Why are certain applications (ls, cp, cd) ported to use SELinux 
> with the standard names, while others
> (spasswd, schfn) have a prefix added?

Look in selinux/utils/spasswd/README in the source distribution for an
explanation


--
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: SELinux question?

[Stephen D. Smalley]

>So they did it because it was easier to wrap the application then to 
>change the code, correct?

See selinux/utils/spasswd/README.  Originally, spasswd was only a
wrapper that served as a "gate" for allowing ordinary users to change
their own passwords while preventing the superuser from arbitrarily
changing other user's passwords.  At that time, the functionality was
easily provided by a wrapper, and there was still a case where direct
execution of the ordinary passwd program was legitimate (execution by
an authorized administrator in sysadm_t to change another user's password).

The wrapper was later extended by Russell Coker to also relabel
/etc/passwd and /etc/shadow after an update in order to support
different security contexts on /etc/passwd and /etc/shadow.  With this
change, it became necessary for authorized administrators to also run
wrapper programs (sadminpasswd, svipw, sadduser, etc) in order to also
preserve these contexts.  

As noted in the README, it would be preferable to modify the base
utilities to use the _secure interfaces to create each file with its
proper context rather than relying on a wrapper to relabel them after
the transaction.  Otherwise, there is a window in which the /etc/passwd
file is left in a more restricted context than desired in order to
preserve the protection of /etc/shadow.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


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