ps aux output under sysadm context in refpolicy

ps aux output under sysadm context in refpolicy

[Jeremiah Jahn]

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

I'm having a heck of a time limiting the ps aux output to show only what
I think sysadm should be able to see.

I have a number of types that are running and I get a ptrace denied, but
sysadm can still see the process. I'm really not sure why this is the
case. I've set all the build options correctly, ie left the defaults,
the booleans are set to no. Somewhere there is something going on that
lets sysadm see all of this stuff, and I just can't find it.

According to apol there is not way for me to read the proc files as
sysadm. What Am I missing, or where should I look.

thanx,
-jj-



He thought he saw an albatross That fluttered 'round the lamp. He looked
again and saw it was A penny postage stamp. "You'd best be getting
home," he said, "The nights are rather damp."

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ps aux output under sysadm context in refpolicy

[Stephen Smalley]

On Thu, 2008-02-21 at 15:22 -0600, Jeremiah Jahn wrote:
> I'm having a heck of a time limiting the ps aux output to show only what
> I think sysadm should be able to see.
> 
> I have a number of types that are running and I get a ptrace denied, but
> sysadm can still see the process. I'm really not sure why this is the
> case. I've set all the build options correctly, ie left the defaults,
> the booleans are set to no. Somewhere there is something going on that
> lets sysadm see all of this stuff, and I just can't find it.
> 
> According to apol there is not way for me to read the proc files as
> sysadm. What Am I missing, or where should I look.

Access to the basic /proc/pid information is allowed by:
	# search the /proc/pid directory for the target domain
	allow <source domain> <target domain>:dir search;
	# read public information about the target domain
	allow <source domain> <target domain>:file read;
since the /proc/pid files are labeled with the domain of the associated
process.

Certain /proc/pid nodes are further limited by ptrace since they reveal
what should be private information to the process.

> 
> thanx,
> -jj-
> 
> 
> 
> He thought he saw an albatross That fluttered 'round the lamp. He looked
> again and saw it was A penny postage stamp. "You'd best be getting
> home," he said, "The nights are rather damp."
-- 
Stephen Smalley
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: ps aux output under sysadm context in refpolicy

[Jeremiah Jahn]

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

I wonder if I'm using apol incorrectly. I have:
Analysis type = Doman Transition
Direction = Forward
source domain = sysadm_t
use access filters = checked
included object types = mysecure_t
included object classes = dir & file
permission for dir = getattr & read & search
permissions for file = getattr & read

results tree = sysadm_t & nothing else, no possible expansions.

I read this as, there is no possible path from sysadm_t to mysecure_t

yet, I get the following output from pas auxZ
system_u:system_r:mysecure_t:s0  mysecure   3531  0.0  0.0 139276  2396 ?        Sl   Feb14   0:00 /usr/local/mysecure/bin/mysecure -Umysecure

I'm stumped :)

On Fri, 2008-02-22 at 09:35 -0500, Stephen Smalley wrote:
> On Thu, 2008-02-21 at 15:22 -0600, Jeremiah Jahn wrote:
> > I'm having a heck of a time limiting the ps aux output to show only what
> > I think sysadm should be able to see.
> > 
> > I have a number of types that are running and I get a ptrace denied, but
> > sysadm can still see the process. I'm really not sure why this is the
> > case. I've set all the build options correctly, ie left the defaults,
> > the booleans are set to no. Somewhere there is something going on that
> > lets sysadm see all of this stuff, and I just can't find it.
> > 
> > According to apol there is not way for me to read the proc files as
> > sysadm. What Am I missing, or where should I look.
> 
> Access to the basic /proc/pid information is allowed by:
> 	# search the /proc/pid directory for the target domain
> 	allow <source domain> <target domain>:dir search;
> 	# read public information about the target domain
> 	allow <source domain> <target domain>:file read;
> since the /proc/pid files are labeled with the domain of the associated
> process.
> 
> Certain /proc/pid nodes are further limited by ptrace since they reveal
> what should be private information to the process.
> 
> > 
> > thanx,
> > -jj-
> > 
> > 
> > 
> > He thought he saw an albatross That fluttered 'round the lamp. He looked
> > again and saw it was A penny postage stamp. "You'd best be getting
> > home," he said, "The nights are rather damp."
Political T.V. commercials prove one thing: some candidates can tell all
their good points and qualifications in just 30 seconds.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ps aux output under sysadm context in refpolicy

[Stephen Smalley]

On Fri, 2008-02-22 at 08:56 -0600, Jeremiah Jahn wrote:
> I wonder if I'm using apol incorrectly. I have:
> Analysis type = Doman Transition
> Direction = Forward
> source domain = sysadm_t
> use access filters = checked
> included object types = mysecure_t
> included object classes = dir & file
> permission for dir = getattr & read & search
> permissions for file = getattr & read
> 
> results tree = sysadm_t & nothing else, no possible expansions.
> 
> I read this as, there is no possible path from sysadm_t to mysecure_t
> 
> yet, I get the following output from pas auxZ
> system_u:system_r:mysecure_t:s0  mysecure   3531  0.0  0.0 139276  2396 ?        Sl   Feb14   0:00 /usr/local/mysecure/bin/mysecure -Umysecure
> 
> I'm stumped :)

Domain transitions are process transitions, i.e. can sysadm_t transition
to mysecure_t.  Not can it read from it.

You can use the rule searching facilities to look for direct read rules,
or can use the information flow analysis to see if there is any path by
which mysecure_t can flow to sysadm_t, but the latter is likely less
useful because there is almost always at least one indirect path by
which information can flow.

> 
> On Fri, 2008-02-22 at 09:35 -0500, Stephen Smalley wrote:
> > On Thu, 2008-02-21 at 15:22 -0600, Jeremiah Jahn wrote:
> > > I'm having a heck of a time limiting the ps aux output to show only what
> > > I think sysadm should be able to see.
> > > 
> > > I have a number of types that are running and I get a ptrace denied, but
> > > sysadm can still see the process. I'm really not sure why this is the
> > > case. I've set all the build options correctly, ie left the defaults,
> > > the booleans are set to no. Somewhere there is something going on that
> > > lets sysadm see all of this stuff, and I just can't find it.
> > > 
> > > According to apol there is not way for me to read the proc files as
> > > sysadm. What Am I missing, or where should I look.
> > 
> > Access to the basic /proc/pid information is allowed by:
> > 	# search the /proc/pid directory for the target domain
> > 	allow <source domain> <target domain>:dir search;
> > 	# read public information about the target domain
> > 	allow <source domain> <target domain>:file read;
> > since the /proc/pid files are labeled with the domain of the associated
> > process.
> > 
> > Certain /proc/pid nodes are further limited by ptrace since they reveal
> > what should be private information to the process.
> > 
> > > 
> > > thanx,
> > > -jj-
> > > 
> > > 
> > > 
> > > He thought he saw an albatross That fluttered 'round the lamp. He looked
> > > again and saw it was A penny postage stamp. "You'd best be getting
> > > home," he said, "The nights are rather damp."
> Political T.V. commercials prove one thing: some candidates can tell all
> their good points and qualifications in just 30 seconds.
-- 
Stephen Smalley
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: ps aux output under sysadm context in refpolicy

[Jeremiah Jahn]

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

okay, done, apparently I have some attribute set some place, but apol
only shows it a @ttr2718 Is there some way I can get this to translate
to English? I'm not that familiar with apol.

On Fri, 2008-02-22 at 10:01 -0500, Stephen Smalley wrote:
> On Fri, 2008-02-22 at 08:56 -0600, Jeremiah Jahn wrote:
> > I wonder if I'm using apol incorrectly. I have:
> > Analysis type = Doman Transition
> > Direction = Forward
> > source domain = sysadm_t
> > use access filters = checked
> > included object types = mysecure_t
> > included object classes = dir & file
> > permission for dir = getattr & read & search
> > permissions for file = getattr & read
> > 
> > results tree = sysadm_t & nothing else, no possible expansions.
> > 
> > I read this as, there is no possible path from sysadm_t to mysecure_t
> > 
> > yet, I get the following output from pas auxZ
> > system_u:system_r:mysecure_t:s0  mysecure   3531  0.0  0.0 139276  2396 ?        Sl   Feb14   0:00 /usr/local/mysecure/bin/mysecure -Umysecure
> > 
> > I'm stumped :)
> 
> Domain transitions are process transitions, i.e. can sysadm_t transition
> to mysecure_t.  Not can it read from it.
> 
> You can use the rule searching facilities to look for direct read rules,
> or can use the information flow analysis to see if there is any path by
> which mysecure_t can flow to sysadm_t, but the latter is likely less
> useful because there is almost always at least one indirect path by
> which information can flow.
> 
> > 
> > On Fri, 2008-02-22 at 09:35 -0500, Stephen Smalley wrote:
> > > On Thu, 2008-02-21 at 15:22 -0600, Jeremiah Jahn wrote:
> > > > I'm having a heck of a time limiting the ps aux output to show only what
> > > > I think sysadm should be able to see.
> > > > 
> > > > I have a number of types that are running and I get a ptrace denied, but
> > > > sysadm can still see the process. I'm really not sure why this is the
> > > > case. I've set all the build options correctly, ie left the defaults,
> > > > the booleans are set to no. Somewhere there is something going on that
> > > > lets sysadm see all of this stuff, and I just can't find it.
> > > > 
> > > > According to apol there is not way for me to read the proc files as
> > > > sysadm. What Am I missing, or where should I look.
> > > 
> > > Access to the basic /proc/pid information is allowed by:
> > > 	# search the /proc/pid directory for the target domain
> > > 	allow <source domain> <target domain>:dir search;
> > > 	# read public information about the target domain
> > > 	allow <source domain> <target domain>:file read;
> > > since the /proc/pid files are labeled with the domain of the associated
> > > process.
> > > 
> > > Certain /proc/pid nodes are further limited by ptrace since they reveal
> > > what should be private information to the process.
> > > 
> > > > 
> > > > thanx,
> > > > -jj-
> > > > 
> > > > 
> > > > 
> > > > He thought he saw an albatross That fluttered 'round the lamp. He looked
> > > > again and saw it was A penny postage stamp. "You'd best be getting
> > > > home," he said, "The nights are rather damp."
> > Political T.V. commercials prove one thing: some candidates can tell all
> > their good points and qualifications in just 30 seconds.
With every passing hour our solar system comes forty-three thousand
miles closer to globular cluster M13 in the constellation Hercules, and
still there are some misfits who continue to insist that there is no
such thing as progress. -- Ransom K. Ferm

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ps aux output under sysadm context in refpolicy

[Stephen Smalley]

On Fri, 2008-02-22 at 09:19 -0600, Jeremiah Jahn wrote:
> okay, done, apparently I have some attribute set some place, but apol
> only shows it a @ttr2718 Is there some way I can get this to translate
> to English? I'm not that familiar with apol.

Kernel policy doesn't preserve attribute names in the symbol table,
because it doesn't need them (my fault).

To get the attribute name, you'd need to run the analysis on the modular
policy or source policy instead.  The current version of apol can load
up any form of policy.

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

Gen_require scoping?

[selinux]

Hi all,

we're trying to setup an JBoss-module. As you probably know JBoss needs
Java and vice versa.

For this we created an .te and if. Part of the .if is an interface to
allow writing logfiles. Relevant part:

########################################
## <summary>
##	Allow the specified domain to
##	write jboss log files
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`jboss_write_log',`
	gen_require(`
		type jboss_log_t;
	')
	logging_search_logs($1)
	allow $1 jboss_log_t:dir list_dir_perms;
	allow $1 jboss_log_t:dir rw_dir_perms;
	allow $1 jboss_log_t:file read_file_perms;
	write_files_pattern($1,jboss_log_t,jboss_log_t);
	allow $1 jboss_log_t:dir search_dir_perms;
        allow $1 jboss_log_t:dir getattr_dir_perms;
')

However, when compiling this modules, all fails at "allow $1
jboss_log_t:dir list_dir_perms;" with this error:

Compiling targeted base module
/usr/bin/checkmodule -M -U allow base.conf -o tmp/base.mod
/usr/bin/checkmodule:  loading policy configuration from base.conf
policy/modules/apps/java.te:22:ERROR 'unknown type jboss_log_t' at token
';' on line 491016:
#line 22
        allow java_t jboss_log_t:dir { getattr search read lock ioctl };
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/base.mod] Error 1

Just to try, we declared "type jboss_log_t;" before logging_search_logs
and after the gen_require. After this I was able to compile the module
(but did run into other problems)...

So, I believe I have an scoping issue; gen_require checks (and find)
jboss_log_t. But as soon as someone is trying to use jboss_log_t in the
interface, it breaks..

To make everything clear:
We changed java.te and added:

#Java needs access to jboss_log_t
jboss_write_log(java_t);

What I am doing wrong here??

Cheers,

Bart



--
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: Gen_require scoping?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

selinux@a61.nl wrote:
> Hi all,
> 
> we're trying to setup an JBoss-module. As you probably know JBoss needs
> Java and vice versa.
> 
> For this we created an .te and if. Part of the .if is an interface to
> allow writing logfiles. Relevant part:
> 
> ########################################
> ## <summary>
> ##	Allow the specified domain to
> ##	write jboss log files
> ## </summary>
> ## <param name="domain">
> ##	<summary>
> ##	Domain allowed access.
> ##	</summary>
> ## </param>
> #
> interface(`jboss_write_log',`
> 	gen_require(`
> 		type jboss_log_t;
> 	')
> 	logging_search_logs($1)
> 	allow $1 jboss_log_t:dir list_dir_perms;
> 	allow $1 jboss_log_t:dir rw_dir_perms;
> 	allow $1 jboss_log_t:file read_file_perms;
> 	write_files_pattern($1,jboss_log_t,jboss_log_t);
> 	allow $1 jboss_log_t:dir search_dir_perms;
>         allow $1 jboss_log_t:dir getattr_dir_perms;
> ')
> 
> However, when compiling this modules, all fails at "allow $1
> jboss_log_t:dir list_dir_perms;" with this error:
> 
> Compiling targeted base module
> /usr/bin/checkmodule -M -U allow base.conf -o tmp/base.mod
> /usr/bin/checkmodule:  loading policy configuration from base.conf
> policy/modules/apps/java.te:22:ERROR 'unknown type jboss_log_t' at token
> ';' on line 491016:
> #line 22
>         allow java_t jboss_log_t:dir { getattr search read lock ioctl };
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> make: *** [tmp/base.mod] Error 1
> 
> Just to try, we declared "type jboss_log_t;" before logging_search_logs
> and after the gen_require. After this I was able to compile the module
> (but did run into other problems)...
> 
> So, I believe I have an scoping issue; gen_require checks (and find)
> jboss_log_t. But as soon as someone is trying to use jboss_log_t in the
> interface, it breaks..
> 
> To make everything clear:
> We changed java.te and added:
> 
> #Java needs access to jboss_log_t
> jboss_write_log(java_t);
> 
> What I am doing wrong here??
> 
> Cheers,
> 
> Bart
> 
> 
> 
> --
> 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.
No your module needs a te file that defined jboss_log_t, not just the
interface, and probably need a file context file.

cat jboss.te

type jboss_log_t;
logging_file_type(jboss_log_t)

cat jboss.fc
/var/log/jboss.*  gen_context(system_u:object_r:jboss_log_t,s0)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke/AjAACgkQrlYvE4MpobP52QCgopXRW8J10kAKL3T4XULq077o
u5QAoNcSqVRUryRI52Vo88qeZY+1V1ip
=z13R
-----END PGP SIGNATURE-----

--
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: Gen_require scoping?

[selinux]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> selinux@a61.nl wrote:
>> Hi all,
>>
>> we're trying to setup an JBoss-module. As you probably know JBoss needs
>> Java and vice versa.
>>
>> For this we created an .te and if. Part of the .if is an interface to
>> allow writing logfiles. Relevant part:
>> What I am doing wrong here??
>>
>> Cheers,
>>
>> Bart
>>
>>
> No your module needs a te file that defined jboss_log_t, not just the
> interface, and probably need a file context file.
>
> cat jboss.te
>
> type jboss_log_t;
> logging_file_type(jboss_log_t)
>
> cat jboss.fc
> /var/log/jboss.*  gen_context(system_u:object_r:jboss_log_t,s0)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAke/AjAACgkQrlYvE4MpobP52QCgopXRW8J10kAKL3T4XULq077o
> u5QAoNcSqVRUryRI52Vo88qeZY+1V1ip
> =z13R
> -----END PGP SIGNATURE-----
>
> --
> 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.
>

Hi Daniel,

We (Bart and I) just pasted the relevant part of our module. To be more
complete I pasted the whole module (so the jboss.te, jboss.if and the
jboss.fc) at the following urls:


http://pastebin.ca/914239
http://pastebin.ca/914240
http://pastebin.ca/914243

The only difference I can see in you statement and ours is this:

Our jboss.te:
type jboss_log_t;
logging_log_file(jboss_log_t)

Your jboss.te example:

type jboss_log_t;
logging_file_type(jboss_log_t)

Our jboss.fc:
/var/log/jboss(/.*)?	gen_context(system_u:object_r:jboss_log_t,s0)

Your jboss.fc example:
/var/log/jboss.*  gen_context(system_u:object_r:jboss_log_t,s0)

Is that difference the reason why jboss_log_t isn't available to other
modules?

Cheers,


Ronald


--
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: Gen_require scoping?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

selinux@a61.nl wrote:
> selinux@a61.nl wrote:
>>>> Hi all,
>>>>
>>>> we're trying to setup an JBoss-module. As you probably know JBoss needs
>>>> Java and vice versa.
>>>>
>>>> For this we created an .te and if. Part of the .if is an interface to
>>>> allow writing logfiles. Relevant part:
>>>> What I am doing wrong here??
>>>>
>>>> Cheers,
>>>>
>>>> Bart
>>>>
>>>>
> No your module needs a te file that defined jboss_log_t, not just the
> interface, and probably need a file context file.
> 
> cat jboss.te
> 
> type jboss_log_t;
> logging_file_type(jboss_log_t)
> 
> cat jboss.fc
> /var/log/jboss.*  gen_context(system_u:object_r:jboss_log_t,s0)
> 
>>
- --
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.
>>

> Hi Daniel,

> We (Bart and I) just pasted the relevant part of our module. To be more
> complete I pasted the whole module (so the jboss.te, jboss.if and the
> jboss.fc) at the following urls:


> http://pastebin.ca/914239
> http://pastebin.ca/914240
> http://pastebin.ca/914243

> The only difference I can see in you statement and ours is this:

> Our jboss.te:
> type jboss_log_t;
> logging_log_file(jboss_log_t)

> Your jboss.te example:

> type jboss_log_t;
> logging_file_type(jboss_log_t)

> Our jboss.fc:
> /var/log/jboss(/.*)?	gen_context(system_u:object_r:jboss_log_t,s0)

> Your jboss.fc example:
> /var/log/jboss.*  gen_context(system_u:object_r:jboss_log_t,s0)

> Is that difference the reason why jboss_log_t isn't available to other
> modules?

> Cheers,


> Ronald

logging_log_file
is correct

You should have a files_type

Updated
http://pastebin.ca/914287

Everything else looks ok.  Is jboss running as jboss_t?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke/J50ACgkQrlYvE4MpobOpBgCaAvbP+/afkqtpt01dD19c42d9
rPMAn3c3rbumQjcbmtriKFzYDXT2utWZ
=KYnl
-----END PGP SIGNATURE-----

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