Re: SELinux question..

Re: SELinux question..

[Stephen Smalley]

On 02/05/2014 07:52 AM, Eric Paris wrote:
> So Casey's comments don't actually make any sense to me at all.  The
> AVC is just a cache of previous results of policy lookups.  The policy
> is fscking huge and looking up a permission takes forever.  that's a
> given, not much we can do about that part.  Now how well SELinux
> caches those results can certainly possibly be looked at....
> 
> I certainly have no objection to using a u64 for ssid and tsid.
> 
> Paul more and I sorta talked and debated about pushing tclass into the
> same u64.  tclass can easily fit in 8 bits (we could fit in 7, but
> that doesn't really do anything).  So
> 
> struct ssid_tsid_tclass {
>       u64 ssid:28, tsid:28, tclass:8;
> );
> 
> It's clearly doable, and we won't *cough* have any trouble today.
> Sids are created sequentially.  You get one sid per unique context.
> It's 'possible' to already overrid the u32 (and you'll start getting
> ENOMEM to all sorts of things if you do)  Paul is particularly worried
> that when/if we run up on the new 268M unique sids (2^28) someday,
> years down the line, you/users/people are going to scream and scream
> when we want those couple of bits back.  We'd need to remove tclass
> from the u64.  Personally I'm ok with that.  I'd rather not pay a
> performance penalty today for what we think will be a problem someday
> down the road...
> 
> Maybe I can try to prototype something.  What patch did you use?  What
> type of performance gains were you able to note?  How did you get your
> perf data?

(cc selinux list)

The greatest use of unique security contexts (and thus SIDs) will be in
setups making extensive use of the SELinux MLS/MCS category sets, as we
typically define 1024 categories in policy (and more are possible) and
they are sets, not just a single value.  So users with MLS policies,
users making extensive use of svirt, openshift, or any other user of MCS
under targeted policy, etc.

If you shrink tclass in the AVC, don't do it in the security server, as
the security policy may include userspace security classes checked via
/sys/fs/selinux/access but the kernel AVC will only ever hold kernel
class indices.

> 
> -Eric
> 
> On Tue, Feb 4, 2014 at 6:13 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 2/4/2014 2:37 PM, Linus Torvalds wrote:
>>> I'm looking at profiles once more, and (once more) being annoying by
>>> SELinux overheads..
>>>
>>> One thing strikes me: does the ssid/tsid space need to be a full 32
>>> bit? Right now the indexing is done by <ssid,tsid,tclass>, and that's
>>> a <u32,u32,u16> tuple..
>>>
>>> I actually improved code generation on x86-64 noticeably by encoding
>>> the ssid+tsid in one 64-bit register, which lowers register pressure
>>> (no frame accesses in avc_has_perm_noaudit()) and makes the avc lookup
>>> more efficient. But it would be even better if the whole tuple could
>>> be encoded that way, ie the 'struct avc_entry' could have just one
>>> 64-bit field that contains <ssid,tsid,tclass>.
>>>
>>> It could easily be a structure with basically arbitrary bit boundaries, so
>>>
>>>    struct ssid_tsid_tclass {
>>>       u64 ssid:24, tsid:24, tclass:16;
>>>    );
>>>
>>> would work fine. Or 25/25/14. Or whatever. The high bits of ssid/tsid
>>> don't *seem* to be used in normal setups, but I don't actually know
>>> what the rules are for these things. Do they need to be the full 32
>>> bits? Does tclass need to be 16 bits? Is there some 64-bit packing
>>> that could work?
>>>
>>> (Ok, so the big cost is actually all the cache misses in avc_lookup(),
>>> and it would be a really big deal if there was some way to perhaps
>>> short-circuit that entirely for the case of "user does directory
>>> lookup permission check for a directory inode". If somebody has a way
>>> to do *that* with SELinux, that would be lovely)
>>
>> There is no reason that SELinux couldn't use security blob
>> pointers for filesystem objects and tasks instead of avc lookups.
>> The only places that really need secids are in networking code
>> where security has been begrudgenly granted 32 bits and admonished
>> never to come asking for more. If a pointer were available instead
>> (and Paul Moore has proposed more than one way to do that, at least
>> one of which provided superior cache performance over the existing
>> code) the avc could go away altogether.
>>
>> There are reasons that some developers like the avc mechanism.
>> I will leave the arguments in its favor to them.
>>
>>> .
>>>
>>>                  Linus
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: SELinux question..

[Victor Porton]

MCS also has a use in sandboxing:

http://portonsoft.wordpress.com/2014/01/11/toward-robust-linux-sandbox/

By the way, it would help if you allow more than 1024 categories.

It is a good idea to build a category from the process ID of the calling program.

It can nevertheless be done with the current kernel assigning SEVERAL categories to MCS, having the list of categories determined by the process ID. But calculating several categories from one process ID is silly.

If I'd take the decision, I would allow any (possibly 64 bit) number as a category in MCS. Thus we would just pass process ID to SELinux when programming the sandbox.

P.S. Debian yet does not work well with enforcing SELinux. For this reason I have lied aside my project related with sandboxing for an indefinite time (until SELinux will work with my Debian).

05.02.2014, 16:19, "Stephen Smalley" <sds@tycho.nsa.gov>:
> On 02/05/2014 07:52 AM, Eric Paris wrote:
>
>>  So Casey's comments don't actually make any sense to me at all.  The
>>  AVC is just a cache of previous results of policy lookups.  The policy
>>  is fscking huge and looking up a permission takes forever.  that's a
>>  given, not much we can do about that part.  Now how well SELinux
>>  caches those results can certainly possibly be looked at....
>>
>>  I certainly have no objection to using a u64 for ssid and tsid.
>>
>>  Paul more and I sorta talked and debated about pushing tclass into the
>>  same u64.  tclass can easily fit in 8 bits (we could fit in 7, but
>>  that doesn't really do anything).  So
>>
>>  struct ssid_tsid_tclass {
>>        u64 ssid:28, tsid:28, tclass:8;
>>  );
>>
>>  It's clearly doable, and we won't *cough* have any trouble today.
>>  Sids are created sequentially.  You get one sid per unique context.
>>  It's 'possible' to already overrid the u32 (and you'll start getting
>>  ENOMEM to all sorts of things if you do)  Paul is particularly worried
>>  that when/if we run up on the new 268M unique sids (2^28) someday,
>>  years down the line, you/users/people are going to scream and scream
>>  when we want those couple of bits back.  We'd need to remove tclass
>>  from the u64.  Personally I'm ok with that.  I'd rather not pay a
>>  performance penalty today for what we think will be a problem someday
>>  down the road...
>>
>>  Maybe I can try to prototype something.  What patch did you use?  What
>>  type of performance gains were you able to note?  How did you get your
>>  perf data?
>
> (cc selinux list)
>
> The greatest use of unique security contexts (and thus SIDs) will be in
> setups making extensive use of the SELinux MLS/MCS category sets, as we
> typically define 1024 categories in policy (and more are possible) and
> they are sets, not just a single value.  So users with MLS policies,
> users making extensive use of svirt, openshift, or any other user of MCS
> under targeted policy, etc.
>
> If you shrink tclass in the AVC, don't do it in the security server, as
> the security policy may include userspace security classes checked via
> /sys/fs/selinux/access but the kernel AVC will only ever hold kernel
> class indices.
>
>>  -Eric
>>
>>  On Tue, Feb 4, 2014 at 6:13 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>  On 2/4/2014 2:37 PM, Linus Torvalds wrote:
>>>>  I'm looking at profiles once more, and (once more) being annoying by
>>>>  SELinux overheads..
>>>>
>>>>  One thing strikes me: does the ssid/tsid space need to be a full 32
>>>>  bit? Right now the indexing is done by <ssid,tsid,tclass>, and that's
>>>>  a <u32,u32,u16> tuple..
>>>>
>>>>  I actually improved code generation on x86-64 noticeably by encoding
>>>>  the ssid+tsid in one 64-bit register, which lowers register pressure
>>>>  (no frame accesses in avc_has_perm_noaudit()) and makes the avc lookup
>>>>  more efficient. But it would be even better if the whole tuple could
>>>>  be encoded that way, ie the 'struct avc_entry' could have just one
>>>>  64-bit field that contains <ssid,tsid,tclass>.
>>>>
>>>>  It could easily be a structure with basically arbitrary bit boundaries, so
>>>>
>>>>     struct ssid_tsid_tclass {
>>>>        u64 ssid:24, tsid:24, tclass:16;
>>>>     );
>>>>
>>>>  would work fine. Or 25/25/14. Or whatever. The high bits of ssid/tsid
>>>>  don't *seem* to be used in normal setups, but I don't actually know
>>>>  what the rules are for these things. Do they need to be the full 32
>>>>  bits? Does tclass need to be 16 bits? Is there some 64-bit packing
>>>>  that could work?
>>>>
>>>>  (Ok, so the big cost is actually all the cache misses in avc_lookup(),
>>>>  and it would be a really big deal if there was some way to perhaps
>>>>  short-circuit that entirely for the case of "user does directory
>>>>  lookup permission check for a directory inode". If somebody has a way
>>>>  to do *that* with SELinux, that would be lovely)
>>>  There is no reason that SELinux couldn't use security blob
>>>  pointers for filesystem objects and tasks instead of avc lookups.
>>>  The only places that really need secids are in networking code
>>>  where security has been begrudgenly granted 32 bits and admonished
>>>  never to come asking for more. If a pointer were available instead
>>>  (and Paul Moore has proposed more than one way to do that, at least
>>>  one of which provided superior cache performance over the existing
>>>  code) the avc could go away altogether.
>>>
>>>  There are reasons that some developers like the avc mechanism.
>>>  I will leave the arguments in its favor to them.
>>>>  .
>>>>
>>>>                   Linus
>>>>  --
>>>>  To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>>>>  the body of a message to majordomo@vger.kernel.org
>>>>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>  --
>>  To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>>  the body of a message to majordomo@vger.kernel.org
>>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Victor Porton - http://portonvictor.org

Re: SELinux question..

[Stephen Smalley]

On 02/05/2014 09:41 AM, Victor Porton wrote:
> MCS also has a use in sandboxing:
> 
> http://portonsoft.wordpress.com/2014/01/11/toward-robust-linux-sandbox/
> 
> By the way, it would help if you allow more than 1024 categories.
> 
> It is a good idea to build a category from the process ID of the calling program.
> 
> It can nevertheless be done with the current kernel assigning SEVERAL categories to MCS, having the list of categories determined by the process ID. But calculating several categories from one process ID is silly.
> 
> If I'd take the decision, I would allow any (possibly 64 bit) number as a category in MCS. Thus we would just pass process ID to SELinux when programming the sandbox.
> 
> P.S. Debian yet does not work well with enforcing SELinux. For this reason I have lied aside my project related with sandboxing for an indefinite time (until SELinux will work with my Debian).

Number of categories is policy-defined, not hardcoded, but there are
some current implementation aspects that make it more costly than it
should be to greatly expand them.  Besides, it is trivial to encode IDs
as category sets and this is already demonstrated through a variety of
existing implementations (at least openshift and Android, don't recall
if svirt and/or sandbox do the same).

Re: SELinux question..

[Paul Moore]

[NOTE: also CC'd the SELinux list]

On Wednesday, February 05, 2014 07:52:50 AM Eric Paris wrote:
> So Casey's comments don't actually make any sense to me at all.  The
> AVC is just a cache of previous results of policy lookups.  The policy
> is fscking huge and looking up a permission takes forever.  that's a
> given, not much we can do about that part.

I didn't quite follow Casey's comments entirely either; the SELinux AVC is a 
different topic than the "secid vs blob" discussion.  As Eric already 
mentioned, the [un]availability of security blobs isn't what is requiring the 
use of the AVC, but rather the size/complexity of the policy.

> Now how well SELinux caches those results can certainly possibly be looked
> at....
> 
> I certainly have no objection to using a u64 for ssid and tsid.
> 
> Paul Moore and I sorta talked and debated about pushing tclass into the
> same u64.  tclass can easily fit in 8 bits (we could fit in 7, but
> that doesn't really do anything).

While I'm a bit nervous about shrinking the SID size, I'm not as nervous about 
shrinking the object class (tclass) size as as look at the current Fedora 
policy shows 83 classes which leaves us quite a bit of headroom.  Also, for 
those who may not be SELinux savvy, object classes are not subject to the 
MCS/MLS expansion/explosion that Stephen mentioned (256 seems "ok" to me).

> So
> 
> struct ssid_tsid_tclass {
>       u64 ssid:28, tsid:28, tclass:8;
> );
> 
> It's clearly doable, and we won't *cough* have any trouble today.
> Sids are created sequentially.  You get one sid per unique context.
> It's 'possible' to already overrid the u32 (and you'll start getting
> ENOMEM to all sorts of things if you do)

Just to be clear on this since I think something may have been lost in 
translation ... It is not possible to *overflow* the SID counter as you will 
start getting ENOMEM and Bad Things will likely happen.  It is also not 
possible to reclaim/revoke SID values as it is very difficult (possible?) to 
ensure the represented subject/object is 100% gone from the system; if you 
reclaim a SID value and the original subject/object still exists you will have 
effectively, and silently, relabeled them (changed their security properties) 
which is another Very Bad Thing. 

> ... Paul is particularly worried that when/if we run up on the new 268M
> unique sids (2^28) someday, years down the line ...

We have already seen things that have caused the policy to grow the numbers of 
labels: increasing MLS/MCS categories and sVirt category combinations moving 
from two to three categories.  It doesn't seem that silly to think that this 
will continue to be a trend; people almost always want more capability and 
they almost always want it sooner than I think.

FWIW, currently available SELinux policies, with a limit of 1024 categories, 
already have the ability to exhaust the 32-bit SID limit.

> ... you/users/people are going to scream and scream when we want those
> couple of bits back.  We'd need to remove tclass from the u64.  Personally
> I'm ok with that.  I'd rather not pay a performance penalty today for what
> we think will be a problem someday down the road...

I suppose it all boils down to how important you feel those last four bits are 
in the SID.  Eric doesn't think they will really be needed in the foreseeable 
future, but as for myself, I think we very well might need them and as a 
result I'm very hesitant to shrink the SID space. 

> Maybe I can try to prototype something.  What patch did you use?  What
> type of performance gains were you able to note?  How did you get your
> perf data?

I'm curious too, especially about these comments:

  "I actually improved code generation on x86-64 noticeably by encoding
   the ssid+tsid in one 64-bit register, which lowers register pressure
   (no frame accesses in avc_has_perm_noaudit()) and makes the avc lookup
   more efficient.

It sounds like at the very least we can do some work to combine the ssid and 
tsid values into a single u64 which would have some benefits without any of 
the too-small-SID-space concerns.  Can you share the perf numbers and the 
patch you used?

-Paul

> On Tue, Feb 4, 2014 at 6:13 PM, Casey Schaufler <casey@schaufler-ca.com> 
wrote:
> > On 2/4/2014 2:37 PM, Linus Torvalds wrote:
> >> I'm looking at profiles once more, and (once more) being annoying by
> >> SELinux overheads..
> >> 
> >> One thing strikes me: does the ssid/tsid space need to be a full 32
> >> bit? Right now the indexing is done by <ssid,tsid,tclass>, and that's
> >> a <u32,u32,u16> tuple..
> >> 
> >> I actually improved code generation on x86-64 noticeably by encoding
> >> the ssid+tsid in one 64-bit register, which lowers register pressure
> >> (no frame accesses in avc_has_perm_noaudit()) and makes the avc lookup
> >> more efficient. But it would be even better if the whole tuple could
> >> be encoded that way, ie the 'struct avc_entry' could have just one
> >> 64-bit field that contains <ssid,tsid,tclass>.
> >> 
> >> It could easily be a structure with basically arbitrary bit boundaries,
> >> so
> >> 
> >>    struct ssid_tsid_tclass {
> >>    
> >>       u64 ssid:24, tsid:24, tclass:16;
> >>    
> >>    );
> >> 
> >> would work fine. Or 25/25/14. Or whatever. The high bits of ssid/tsid
> >> don't *seem* to be used in normal setups, but I don't actually know
> >> what the rules are for these things. Do they need to be the full 32
> >> bits? Does tclass need to be 16 bits? Is there some 64-bit packing
> >> that could work?
> >> 
> >> (Ok, so the big cost is actually all the cache misses in avc_lookup(),
> >> and it would be a really big deal if there was some way to perhaps
> >> short-circuit that entirely for the case of "user does directory
> >> lookup permission check for a directory inode". If somebody has a way
> >> to do *that* with SELinux, that would be lovely)
> > 
> > There is no reason that SELinux couldn't use security blob
> > pointers for filesystem objects and tasks instead of avc lookups.
> > The only places that really need secids are in networking code
> > where security has been begrudgenly granted 32 bits and admonished
> > never to come asking for more. If a pointer were available instead
> > (and Paul Moore has proposed more than one way to do that, at least
> > one of which provided superior cache performance over the existing
> > code) the avc could go away altogether.
> > 
> > There are reasons that some developers like the avc mechanism.
> > I will leave the arguments in its favor to them.


-- 
paul moore
www.paul-moore.com

Re: selinux question

[Russell Coker]

On Wed, 17 Jul 2002 04:51, you wrote:
> one thing I am still not clear on, how does selinux know to deny this:
> >chsid system_u:object_r:user_netscape_rw_t ~/untrusted
>
> /home/bam/untrusted: Permission denied
>
> but not this:
> >chsid bam:object_r:user_netscape_rw_t ~/untrusted
>
> Jul 17 12:43:32 scrooge kernel: avc:  denied  { relabelto } for pid=3569
> exe=/usr/bin/chsid path=/bam/untrusted dev=03:09 ino=423537
> scontext=bam:user_r:user_t tcontext=system_u:object_r:user_netscape_rw_t
> tclass=dir
>
> ?
>
> The rule seems to be the same in both cases.
>
> allow user_t user_netscape_rw_t:{ dir file lnk_file } relabelto;

I'm not sure.

I've run into a similar issue, some scripts such as dh_installdocs call "cp 
-a" which tries to do such a chsid and fails.  I think that "cp -a" should 
not preserve sids to avoid breaking compatability in such situations.  
Generally when "cp -a" is called you don't even want to preserve the UID, 
just the mode.

What do you think?

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
You have received this message because you are subscribed to the selinux 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 Smalley]

On Tue, 23 Jul 2002, Russell Coker wrote:

> On Wed, 17 Jul 2002 04:51, you wrote:
> > one thing I am still not clear on, how does selinux know to deny this:
> > >chsid system_u:object_r:user_netscape_rw_t ~/untrusted
> >
> > /home/bam/untrusted: Permission denied
> >
> > but not this:
> > >chsid bam:object_r:user_netscape_rw_t ~/untrusted

The first operation is denied by the policy/constraints configuration.  As
noted in the Configuring the SELinux Policy report, the constraint
definitions specify additional restrictions on permissions that can be
based on a combination of information from the user identity, TE, and RBAC
models.  These additional restrictions are specified as boolean
expressions that must be satisfied in order for certain permissions to be
granted.  The relevant statement from policy/constraints is:

constrain dir_file_class_set { create relabelto relabelfrom }
	( u1 == u2 or t1 == privowner );

This statement limits the ability to create or relabel files with
different user identities to domains that have the "privowner" attribute.

> I've run into a similar issue, some scripts such as dh_installdocs call "cp
> -a" which tries to do such a chsid and fails.  I think that "cp -a" should
> not preserve sids to avoid breaking compatability in such situations.
> Generally when "cp -a" is called you don't even want to preserve the UID,
> just the mode.
>
> What do you think?

cp -a or cp -p does attempt to preserve the owner and group as well as the
mode.  cp -a or cp -p will treat a failed chown as an error if the user is
root but will silently ignore failure if the user is non-root.  The
comment from the code says "If non-root uses -p, it's ok if we can't
preserve ownership. But root probably wants to know, e.g. if NFS disallows
it, or if the target system doesn't support file ownership."  The same
copying code is used by cp, install, and mv (for cross-filesystem moves).

We could have these utilities merely warn on failed chsid calls and not
return an error by default.  However, if we make such a change, we should
definitely add a command line option to force the utility to treat it as
an error for cases where this is desired.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com






--
You have received this message because you are subscribed to the selinux 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

[Russell Coker]

On Tue, 23 Jul 2002 16:03, Stephen Smalley wrote:
> The first operation is denied by the policy/constraints configuration.  As

Thanks.

> > I've run into a similar issue, some scripts such as dh_installdocs call
> > "cp -a" which tries to do such a chsid and fails.  I think that "cp -a"
> > should not preserve sids to avoid breaking compatability in such
> > situations. Generally when "cp -a" is called you don't even want to
> > preserve the UID, just the mode.
> >
> > What do you think?
>
> cp -a or cp -p does attempt to preserve the owner and group as well as the
> mode.  cp -a or cp -p will treat a failed chown as an error if the user is
> root but will silently ignore failure if the user is non-root.  The
> comment from the code says "If non-root uses -p, it's ok if we can't
> preserve ownership. But root probably wants to know, e.g. if NFS disallows
> it, or if the target system doesn't support file ownership."  The same
> copying code is used by cp, install, and mv (for cross-filesystem moves).
>
> We could have these utilities merely warn on failed chsid calls and not
> return an error by default.  However, if we make such a change, we should
> definitely add a command line option to force the utility to treat it as
> an error for cases where this is desired.

My problem is with a program that thinks it's root but isn't.  For creating 
Debian packages we use a system called "fakeroot" which uses a LD_PRELOAD 
hack to override the getuid() system call and make a process think it's root. 
It also overrides the chown() and stat() system calls to make it look as if 
the file has changed ownership.

Maybe I should make the SE Linux programs use a shared object for the system 
call wrapper functions so that I can use a LD_PRELOAD hack to take over SE 
Linux system calls and replace them with my own equivalents.  What do you 
think?

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
You have received this message because you are subscribed to the selinux 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

[Brian May]

On Tue, 2002-07-23 at 23:19, Russell Coker wrote:
> I've run into a similar issue, some scripts such as dh_installdocs call "cp 
> -a" which tries to do such a chsid and fails.  I think that "cp -a" should 
> not preserve sids to avoid breaking compatability in such situations.  
> Generally when "cp -a" is called you don't even want to preserve the UID, 
> just the mode.

I have to ask why does dh_installdocs use cp -a, and not cp -dR.

It doesn't need to copy ownership or group, or permissions, as these
will be reset later on by dh_fixperms.

It doesn't want to copy SIDs, as even if (or when) tar supported this, I
don't think you want Debian packages to come supplied with built in
SIDs.
-- 
Brian May <bam@snoopy.apana.org.au>


--
You have received this message because you are subscribed to the selinux 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

[Russell Coker]

On Wed, 24 Jul 2002 02:25, Brian May wrote:
> On Tue, 2002-07-23 at 23:19, Russell Coker wrote:
> > I've run into a similar issue, some scripts such as dh_installdocs call
> > "cp -a" which tries to do such a chsid and fails.  I think that "cp -a"
> > should not preserve sids to avoid breaking compatability in such
> > situations. Generally when "cp -a" is called you don't even want to
> > preserve the UID, just the mode.
>
> I have to ask why does dh_installdocs use cp -a, and not cp -dR.
>
> It doesn't need to copy ownership or group, or permissions, as these
> will be reset later on by dh_fixperms.
>
> It doesn't want to copy SIDs, as even if (or when) tar supported this, I
> don't think you want Debian packages to come supplied with built in
> SIDs.

Good point.  I've filed a bug report against dh_installdocs.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
You have received this message because you are subscribed to the selinux 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

[Westerman, Mark]

To all,

I have been try to get selinux running on a Redhat 7 box. I have the
kernel running in debug mode and i am try to get rid of the denied messages

I am work on the /sbin/hwclock program.

Thanks
Mark Westerman
mark.westerman@csoconline.com



Here are the rules


file:   domains/system/hwclock.te
#################################
#
# Rules for the hwclock_t domain.
#
type hwclock_t, domain, privlog;
type hwclock_exec_t, file_type, sysadmfile, exec_type;

# Use capabilities.
allow hwclock_t self:capability { sys_admin };

# Inherit and use descriptors from init.
#allow hwclock_t init_t:fd inherit_fd_perms;

# Use a pipe created by initrc_t.
#allow hwclock_t initrc_t:pipe rw_file_perms;

# Read and write ttys.
allow hwclock_t tty_device_t:chr_file rw_file_perms;


file: domains/system/initrc.te

domain_auto_trans(initrc_t, hwclock_exec_t, hwclock_t)


file:  file_context
/sbin/hwclock                   system_u:object_r:hwclock_exec_t


ls --scontext /sbin/hwclock

system_u:object_r:hwclock_exec_t /sbin/hwclock


file: /var/log/messages

security_compute_sid:  invalid context system_u:system_r:hwclock_t 
        for scontext=system_u:system_r:initrc_t 
              tcontext=system_u:object_r:hwclock_exec_t tclass=process


--
You have received this message because you are subscribed to the selinux 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

[Jen Salois]

Mark,

	I am assuming that hwclock is getting started from an init script,
since I see the transition of initrc_t to the hwclock_t.  Well when the
hwclock is started by an init script it is also inheriting the role from
initrc.  The role this operates under is system_r.  Also the error
message is saying there is no hwclock_t associated with the system_r
role.  What you need to do is have a role transition in the policy also. 

You do a role transition in the rbac file.  It is in the form of 

role_transition current_role program_type new_role;

Hope that helps.

Thanks

Jen


> To all,
> 
> I have been try to get selinux running on a Redhat 7 box. I have the
> kernel running in debug mode and i am try to get rid of the denied messages
> 
> I am work on the /sbin/hwclock program.
> 
> Thanks
> Mark Westerman
> mark.westerman@csoconline.com
> 
> Here are the rules
> 
> file:   domains/system/hwclock.te
> #################################
> #
> # Rules for the hwclock_t domain.
> #
> type hwclock_t, domain, privlog;
> type hwclock_exec_t, file_type, sysadmfile, exec_type;
> 
> # Use capabilities.
> allow hwclock_t self:capability { sys_admin };
> 
> # Inherit and use descriptors from init.
> #allow hwclock_t init_t:fd inherit_fd_perms;
> 
> # Use a pipe created by initrc_t.
> #allow hwclock_t initrc_t:pipe rw_file_perms;
> 
> # Read and write ttys.
> allow hwclock_t tty_device_t:chr_file rw_file_perms;
> 
> file: domains/system/initrc.te
> 
> domain_auto_trans(initrc_t, hwclock_exec_t, hwclock_t)
> 
> file:  file_context
> /sbin/hwclock                   system_u:object_r:hwclock_exec_t
> 
> ls --scontext /sbin/hwclock
> 
> system_u:object_r:hwclock_exec_t /sbin/hwclock
> 
> file: /var/log/messages
> 
> security_compute_sid:  invalid context system_u:system_r:hwclock_t
>         for scontext=system_u:system_r:initrc_t
>               tcontext=system_u:object_r:hwclock_exec_t tclass=process
> 
> --
> You have received this message because you are subscribed to the selinux 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.

--
You have received this message because you are subscribed to the selinux 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 Smalley]

You need to add the hwclock_t type to the definition of the
system_r role in policy/rbac. 

By the way, we are currently preparing an updated release 
based on the 2.4.1 kernel.  The old 2.2 patch will also be
updated in the new release for 2.2.18.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com


On Mon, 12 Feb 2001, Westerman, Mark wrote:

> To all,
> 
> I have been try to get selinux running on a Redhat 7 box. I have the
> kernel running in debug mode and i am try to get rid of the denied messages
> 
> I am work on the /sbin/hwclock program.
> 
> Thanks
> Mark Westerman
> mark.westerman@csoconline.com
> 
> 
> 
> Here are the rules
> 
> 
> file:   domains/system/hwclock.te
> #################################
> #
> # Rules for the hwclock_t domain.
> #
> type hwclock_t, domain, privlog;
> type hwclock_exec_t, file_type, sysadmfile, exec_type;
> 
> # Use capabilities.
> allow hwclock_t self:capability { sys_admin };
> 
> # Inherit and use descriptors from init.
> #allow hwclock_t init_t:fd inherit_fd_perms;
> 
> # Use a pipe created by initrc_t.
> #allow hwclock_t initrc_t:pipe rw_file_perms;
> 
> # Read and write ttys.
> allow hwclock_t tty_device_t:chr_file rw_file_perms;
> 
> 
> file: domains/system/initrc.te
> 
> domain_auto_trans(initrc_t, hwclock_exec_t, hwclock_t)
> 
> 
> file:  file_context
> /sbin/hwclock                   system_u:object_r:hwclock_exec_t
> 
> 
> ls --scontext /sbin/hwclock
> 
> system_u:object_r:hwclock_exec_t /sbin/hwclock
> 
> 
> file: /var/log/messages
> 
> security_compute_sid:  invalid context system_u:system_r:hwclock_t 
>         for scontext=system_u:system_r:initrc_t 
>               tcontext=system_u:object_r:hwclock_exec_t tclass=process
> 
> 
> --
> You have received this message because you are subscribed to the selinux 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.
> 


--
You have received this message because you are subscribed to the selinux 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.