Question about newrole

Question about newrole

[Dennis Wronka]

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

Hi folks,

I'd like to ask about a problem I am experiencing with newrole.
When I use newrole in permissive-mode I have no problems changing the role. 
Also I don't get any audit-messages.
But when I switch to enforcing-mode I cannot use newrole, it keeps telling 
me "incorrect password for root", although it clearly is correct.
I suspect a problem in interaction between newrole and unix_chkpwd, but am not 
entirely sure about it.

Problem is that I don't get any audits from SELinux, only errors in auth.log 
from unix_chkpwd:
check_pass; user unknown
password check failer for user (root)

I am working with the latest reference-policy, adjusted here and there to fit 
the needs of my distro.

Thanks for any suggestions.

Dennis

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

Re: Question about newrole

[Stephen Smalley]

On Tue, 2008-08-05 at 21:55 +0800, Dennis Wronka wrote:
> Hi folks,
> 
> I'd like to ask about a problem I am experiencing with newrole.
> When I use newrole in permissive-mode I have no problems changing the role. 
> Also I don't get any audit-messages.
> But when I switch to enforcing-mode I cannot use newrole, it keeps telling 
> me "incorrect password for root", although it clearly is correct.
> I suspect a problem in interaction between newrole and unix_chkpwd, but am not 
> entirely sure about it.
> 
> Problem is that I don't get any audits from SELinux, only errors in auth.log 
> from unix_chkpwd:
> check_pass; user unknown
> password check failer for user (root)
> 
> I am working with the latest reference-policy, adjusted here and there to fit 
> the needs of my distro.
> 
> Thanks for any suggestions.

What version of pam are you using?  What distro?
There were changes made to pam_unix and unix_chkpwd for selinux.
Also, how are you building newrole?

-- 
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: Question about newrole

[Xavier Toth]

On Tue, Aug 5, 2008 at 8:55 AM, Dennis Wronka <linuxweb@gmx.net> wrote:
> Hi folks,
>
> I'd like to ask about a problem I am experiencing with newrole.
> When I use newrole in permissive-mode I have no problems changing the role.
> Also I don't get any audit-messages.
> But when I switch to enforcing-mode I cannot use newrole, it keeps telling
> me "incorrect password for root", although it clearly is correct.
> I suspect a problem in interaction between newrole and unix_chkpwd, but am not
> entirely sure about it.
>
> Problem is that I don't get any audits from SELinux, only errors in auth.log
> from unix_chkpwd:
> check_pass; user unknown
> password check failer for user (root)
>
> I am working with the latest reference-policy, adjusted here and there to fit
> the needs of my distro.
>
> Thanks for any suggestions.
>
> Dennis
>

You can try using `semodule -DB` to turn off the dontaudits and see if
you get any AVCs then.

--
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: Question about newrole

[Dennis Wronka]

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

Just for the record, sent the initial reply to Stephen only.
Sorry for the glitch.

Rest at the bottom.

On Tuesday 05 August 2008 22:13:34 Stephen Smalley wrote:
> On Tue, 2008-08-05 at 21:55 +0800, Dennis Wronka wrote:
> > Hi folks,
> >
> > I'd like to ask about a problem I am experiencing with newrole.
> > When I use newrole in permissive-mode I have no problems changing the
> > role. Also I don't get any audit-messages.
> > But when I switch to enforcing-mode I cannot use newrole, it keeps
> > telling me "incorrect password for root", although it clearly is correct.
> > I suspect a problem in interaction between newrole and unix_chkpwd, but
> > am not entirely sure about it.
> >
> > Problem is that I don't get any audits from SELinux, only errors in
> > auth.log from unix_chkpwd:
> > check_pass; user unknown
> > password check failer for user (root)
> >
> > I am working with the latest reference-policy, adjusted here and there to
> > fit the needs of my distro.
> >
> > Thanks for any suggestions.
>
> What version of pam are you using?  What distro?
> There were changes made to pam_unix and unix_chkpwd for selinux.
> Also, how are you building newrole?

I am using PAM 1.0.1 on the current development-version of EasyLFS. I am 
currently working on the integration of SELinux and seem to be hanging on 
this point.
I haven't set much focus towards newrole in the previous releases, but want to 
do so now.
newrole is the one from the policycoreutils 2.0.49, built simply with make && 
make install.

Btw, I think the same problem applies to run_init, will have to check to 
confirm though.

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

Re: Question about newrole

[Dennis Wronka]

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

Thanks.
That seems to help quite a bit.
I now get some messages. For example it seems that newrole wants to 
read /etc/shadow directly.
Will check those messages and play around with the policy.

On Tuesday 05 August 2008 22:17:19 Xavier Toth wrote:
> On Tue, Aug 5, 2008 at 8:55 AM, Dennis Wronka <linuxweb@gmx.net> wrote:
> > Hi folks,
> >
> > I'd like to ask about a problem I am experiencing with newrole.
> > When I use newrole in permissive-mode I have no problems changing the
> > role. Also I don't get any audit-messages.
> > But when I switch to enforcing-mode I cannot use newrole, it keeps
> > telling me "incorrect password for root", although it clearly is correct.
> > I suspect a problem in interaction between newrole and unix_chkpwd, but
> > am not entirely sure about it.
> >
> > Problem is that I don't get any audits from SELinux, only errors in
> > auth.log from unix_chkpwd:
> > check_pass; user unknown
> > password check failer for user (root)
> >
> > I am working with the latest reference-policy, adjusted here and there to
> > fit the needs of my distro.
> >
> > Thanks for any suggestions.
> >
> > Dennis
>
> You can try using `semodule -DB` to turn off the dontaudits and see if
> you get any AVCs then.



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

Re: Question about newrole

[Stephen Smalley]

On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
> Thanks.
> That seems to help quite a bit.
> I now get some messages. For example it seems that newrole wants to 
> read /etc/shadow directly.
> Will check those messages and play around with the policy.

The way it works is that pam_unix attempts to open /etc/shadow directly
for reading, and if it fails, it falls back to running unix_chkpwd to
perform the password check.  SELinux policy prohibits most programs from
directly reading /etc/shadow, including even ones that run as root, and
forces them to go through unix_chkpwd instead, in order to limit the set
of processes that have full read access to the shadow password file.

The logic to try to open /etc/shadow and fall back to unix_chkpwd
already existed before SELinux in order to support non-root processes
re-authenticating the current user.  What changed with SELinux was that
it could also happen for root processes.

The current policy dontaudit's the attempt to directly read /etc/shadow
to avoid noise.  When you did semodule -DB, you turned on that auditing.
But those denials are what is expected, and allowing them will mean
giving newrole direct read access to /etc/shadow (although that will
only work if running as root, of course, as otherwise it has to use a
suid helper like unix_chkpwd anyway).

Does newrole work for you as a non-root user?

-- 
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: Question about newrole

[Justin Mattock]

On Tue, Aug 5, 2008 at 7:48 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
>> Thanks.
>> That seems to help quite a bit.
>> I now get some messages. For example it seems that newrole wants to
>> read /etc/shadow directly.
>> Will check those messages and play around with the policy.
>
> The way it works is that pam_unix attempts to open /etc/shadow directly
> for reading, and if it fails, it falls back to running unix_chkpwd to
> perform the password check.  SELinux policy prohibits most programs from
> directly reading /etc/shadow, including even ones that run as root, and
> forces them to go through unix_chkpwd instead, in order to limit the set
> of processes that have full read access to the shadow password file.
>
> The logic to try to open /etc/shadow and fall back to unix_chkpwd
> already existed before SELinux in order to support non-root processes
> re-authenticating the current user.  What changed with SELinux was that
> it could also happen for root processes.
>
> The current policy dontaudit's the attempt to directly read /etc/shadow
> to avoid noise.  When you did semodule -DB, you turned on that auditing.
> But those denials are what is expected, and allowing them will mean
> giving newrole direct read access to /etc/shadow (although that will
> only work if running as root, of course, as otherwise it has to use a
> suid helper like unix_chkpwd anyway).
>
> Does newrole work for you as a non-root user?
>
> --
> 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.
>

I usually just type passwd in a terminal
and update the database. then choose you're role
and do the same for that role if need be.
but depending on what you have, this might be a different case.
hope this helps.
regards;

-- 
Justin P. Mattock

--
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: Question about newrole

[Dennis Wronka]

-------- Original-Nachricht --------
> Datum: Tue, 05 Aug 2008 10:48:55 -0400
> Von: Stephen Smalley <sds@tycho.nsa.gov>
> An: Dennis Wronka <linuxweb@gmx.net>
> CC: Xavier Toth <txtoth@gmail.com>, SELinux Mailing List <selinux@tycho.nsa.gov>
> Betreff: Re: Question about newrole

> 
> On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
> > Thanks.
> > That seems to help quite a bit.
> > I now get some messages. For example it seems that newrole wants to 
> > read /etc/shadow directly.
> > Will check those messages and play around with the policy.
> 
> The way it works is that pam_unix attempts to open /etc/shadow directly
> for reading, and if it fails, it falls back to running unix_chkpwd to
> perform the password check.  SELinux policy prohibits most programs from
> directly reading /etc/shadow, including even ones that run as root, and
> forces them to go through unix_chkpwd instead, in order to limit the set
> of processes that have full read access to the shadow password file.
> 
> The logic to try to open /etc/shadow and fall back to unix_chkpwd
> already existed before SELinux in order to support non-root processes
> re-authenticating the current user.  What changed with SELinux was that
> it could also happen for root processes.
> 
> The current policy dontaudit's the attempt to directly read /etc/shadow
> to avoid noise.  When you did semodule -DB, you turned on that auditing.
> But those denials are what is expected, and allowing them will mean
> giving newrole direct read access to /etc/shadow (although that will
> only work if running as root, of course, as otherwise it has to use a
> suid helper like unix_chkpwd anyway).
> 
> Does newrole work for you as a non-root user?
> 
> -- 
> 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.

Also running newrole as regular user (running as staff_u:staff_r:staff_t, trying to transition to sysadm_r) gets me the same message, just with dennis as username.

I also tried setting unix_chkpwd set-uid root already, but even that didn't help.

I'll turn on the audit-messages again and see if there's anything that maybe shows that unix_chkpwd is not allowed to read shadow.
-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

--
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: Question about newrole

[Dennis Wronka]

-------- Original-Nachricht --------
> Datum: Tue, 5 Aug 2008 08:04:34 -0700
> Von: "Justin Mattock" <justinmattock@gmail.com>
> An: "Stephen Smalley" <sds@tycho.nsa.gov>
> CC: "Dennis Wronka" <linuxweb@gmx.net>, "Xavier Toth" <txtoth@gmail.com>, "SELinux Mailing List" <selinux@tycho.nsa.gov>
> Betreff: Re: Question about newrole

> On Tue, Aug 5, 2008 at 7:48 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >
> > On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
> >> Thanks.
> >> That seems to help quite a bit.
> >> I now get some messages. For example it seems that newrole wants to
> >> read /etc/shadow directly.
> >> Will check those messages and play around with the policy.
> >
> > The way it works is that pam_unix attempts to open /etc/shadow directly
> > for reading, and if it fails, it falls back to running unix_chkpwd to
> > perform the password check.  SELinux policy prohibits most programs from
> > directly reading /etc/shadow, including even ones that run as root, and
> > forces them to go through unix_chkpwd instead, in order to limit the set
> > of processes that have full read access to the shadow password file.
> >
> > The logic to try to open /etc/shadow and fall back to unix_chkpwd
> > already existed before SELinux in order to support non-root processes
> > re-authenticating the current user.  What changed with SELinux was that
> > it could also happen for root processes.
> >
> > The current policy dontaudit's the attempt to directly read /etc/shadow
> > to avoid noise.  When you did semodule -DB, you turned on that auditing.
> > But those denials are what is expected, and allowing them will mean
> > giving newrole direct read access to /etc/shadow (although that will
> > only work if running as root, of course, as otherwise it has to use a
> > suid helper like unix_chkpwd anyway).
> >
> > Does newrole work for you as a non-root user?
> >
> > --
> > 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.
> >
> 
> I usually just type passwd in a terminal
> and update the database. then choose you're role
> and do the same for that role if need be.
> but depending on what you have, this might be a different case.
> hope this helps.
> regards;
> 
> -- 
> Justin P. Mattock

What I actually want to use newrole for is not resetting passwords. I was thinking to introduce MLS to the next release and thus require the user to transition to secadm_r if he wants to switch from enforcing to permissive.
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

--
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: Question about newrole

[Justin Mattock]

On Tue, Aug 5, 2008 at 8:10 AM, Dennis Wronka <linuxweb@gmx.net> wrote:
>
> -------- Original-Nachricht --------
>> Datum: Tue, 5 Aug 2008 08:04:34 -0700
>> Von: "Justin Mattock" <justinmattock@gmail.com>
>> An: "Stephen Smalley" <sds@tycho.nsa.gov>
>> CC: "Dennis Wronka" <linuxweb@gmx.net>, "Xavier Toth" <txtoth@gmail.com>, "SELinux Mailing List" <selinux@tycho.nsa.gov>
>> Betreff: Re: Question about newrole
>
>> On Tue, Aug 5, 2008 at 7:48 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> >
>> > On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
>> >> Thanks.
>> >> That seems to help quite a bit.
>> >> I now get some messages. For example it seems that newrole wants to
>> >> read /etc/shadow directly.
>> >> Will check those messages and play around with the policy.
>> >
>> > The way it works is that pam_unix attempts to open /etc/shadow directly
>> > for reading, and if it fails, it falls back to running unix_chkpwd to
>> > perform the password check.  SELinux policy prohibits most programs from
>> > directly reading /etc/shadow, including even ones that run as root, and
>> > forces them to go through unix_chkpwd instead, in order to limit the set
>> > of processes that have full read access to the shadow password file.
>> >
>> > The logic to try to open /etc/shadow and fall back to unix_chkpwd
>> > already existed before SELinux in order to support non-root processes
>> > re-authenticating the current user.  What changed with SELinux was that
>> > it could also happen for root processes.
>> >
>> > The current policy dontaudit's the attempt to directly read /etc/shadow
>> > to avoid noise.  When you did semodule -DB, you turned on that auditing.
>> > But those denials are what is expected, and allowing them will mean
>> > giving newrole direct read access to /etc/shadow (although that will
>> > only work if running as root, of course, as otherwise it has to use a
>> > suid helper like unix_chkpwd anyway).
>> >
>> > Does newrole work for you as a non-root user?
>> >
>> > --
>> > 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.
>> >
>>
>> I usually just type passwd in a terminal
>> and update the database. then choose you're role
>> and do the same for that role if need be.
>> but depending on what you have, this might be a different case.
>> hope this helps.
>> regards;
>>
>> --
>> Justin P. Mattock
>
> What I actually want to use newrole for is not resetting passwords. I was thinking to introduce MLS to the next release and thus require the user to transition to secadm_r if he wants to switch from enforcing to permissive.
> --
> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
> Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
>

O.k.
I thaught you were getting
a permisions denied when entering newrole -r *
I receive this normally on a fresh install, then
after updating the database, everything is good.
regards;

-- 
Justin P. Mattock

--
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: Question about newrole

[Justin Mattock]

On Tue, Aug 5, 2008 at 8:05 AM, Dennis Wronka <linuxweb@gmx.net> wrote:
>
> -------- Original-Nachricht --------
>> Datum: Tue, 05 Aug 2008 10:48:55 -0400
>> Von: Stephen Smalley <sds@tycho.nsa.gov>
>> An: Dennis Wronka <linuxweb@gmx.net>
>> CC: Xavier Toth <txtoth@gmail.com>, SELinux Mailing List <selinux@tycho.nsa.gov>
>> Betreff: Re: Question about newrole
>
>>
>> On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
>> > Thanks.
>> > That seems to help quite a bit.
>> > I now get some messages. For example it seems that newrole wants to
>> > read /etc/shadow directly.
>> > Will check those messages and play around with the policy.
>>
>> The way it works is that pam_unix attempts to open /etc/shadow directly
>> for reading, and if it fails, it falls back to running unix_chkpwd to
>> perform the password check.  SELinux policy prohibits most programs from
>> directly reading /etc/shadow, including even ones that run as root, and
>> forces them to go through unix_chkpwd instead, in order to limit the set
>> of processes that have full read access to the shadow password file.
>>
>> The logic to try to open /etc/shadow and fall back to unix_chkpwd
>> already existed before SELinux in order to support non-root processes
>> re-authenticating the current user.  What changed with SELinux was that
>> it could also happen for root processes.
>>
>> The current policy dontaudit's the attempt to directly read /etc/shadow
>> to avoid noise.  When you did semodule -DB, you turned on that auditing.
>> But those denials are what is expected, and allowing them will mean
>> giving newrole direct read access to /etc/shadow (although that will
>> only work if running as root, of course, as otherwise it has to use a
>> suid helper like unix_chkpwd anyway).
>>
>> Does newrole work for you as a non-root user?
>>
>> --
>> 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.
>
> Also running newrole as regular user (running as staff_u:staff_r:staff_t, trying to transition to sysadm_r) gets me the same message, just with dennis as username.
>
> I also tried setting unix_chkpwd set-uid root already, but even that didn't help.
>
> I'll turn on the audit-messages again and see if there's anything that maybe shows that unix_chkpwd is not allowed to read shadow.
> --
> GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
> http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196
>
> --
> 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.
>

Could be, you might need to make enableaudit
in you're policy directory to see:
allow system_chkpwd_t security_t:dir { getattr search };
allow system_chkpwd_t security_t:file read;
allow system_chkpwd_t security_t:filesystem getattr;

these types of contexts or allow rules to login the role
you want to use.
-- 
Justin P. Mattock


--
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: Question about newrole

[Dennis Wronka]

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

On Tuesday 05 August 2008 22:48:55 Stephen Smalley wrote:
> On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
> > Thanks.
> > That seems to help quite a bit.
> > I now get some messages. For example it seems that newrole wants to
> > read /etc/shadow directly.
> > Will check those messages and play around with the policy.
>
> The way it works is that pam_unix attempts to open /etc/shadow directly
> for reading, and if it fails, it falls back to running unix_chkpwd to
> perform the password check.  SELinux policy prohibits most programs from
> directly reading /etc/shadow, including even ones that run as root, and
> forces them to go through unix_chkpwd instead, in order to limit the set
> of processes that have full read access to the shadow password file.
>
> The logic to try to open /etc/shadow and fall back to unix_chkpwd
> already existed before SELinux in order to support non-root processes
> re-authenticating the current user.  What changed with SELinux was that
> it could also happen for root processes.
>
> The current policy dontaudit's the attempt to directly read /etc/shadow
> to avoid noise.  When you did semodule -DB, you turned on that auditing.
> But those denials are what is expected, and allowing them will mean
> giving newrole direct read access to /etc/shadow (although that will
> only work if running as root, of course, as otherwise it has to use a
> suid helper like unix_chkpwd anyway).
>
> Does newrole work for you as a non-root user?

Okay, it looks like that unix_chkpwd is not allowed to read /etc/shadow when 
running in newrole_t.

Here's the message:
type=1400 audit(1217920543.235:26): avc: denied { read } for pid=1210 
comm="unix_chkpwd" name="shadow" dev=dm-0 ino=29366926 
scontext=staff_u:staff_r:newrole_t tcontext=system_u:object_r:shadow_t 
tclass=file

Is it safe to add the rule suggested by audit2allow "allow newrole_t 
shadow_t:file read;" to the policy or would there be a better way?

Wouldn't it in general be better if unix_chkpwd would transition into a domain 
for itself which then in turn is allowed to access /etc/shadow?

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

Re: Question about newrole

[Stephen Smalley]

On Tue, 2008-08-05 at 23:23 +0800, Dennis Wronka wrote:
> On Tuesday 05 August 2008 22:48:55 Stephen Smalley wrote:
> > On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
> > > Thanks.
> > > That seems to help quite a bit.
> > > I now get some messages. For example it seems that newrole wants to
> > > read /etc/shadow directly.
> > > Will check those messages and play around with the policy.
> >
> > The way it works is that pam_unix attempts to open /etc/shadow directly
> > for reading, and if it fails, it falls back to running unix_chkpwd to
> > perform the password check.  SELinux policy prohibits most programs from
> > directly reading /etc/shadow, including even ones that run as root, and
> > forces them to go through unix_chkpwd instead, in order to limit the set
> > of processes that have full read access to the shadow password file.
> >
> > The logic to try to open /etc/shadow and fall back to unix_chkpwd
> > already existed before SELinux in order to support non-root processes
> > re-authenticating the current user.  What changed with SELinux was that
> > it could also happen for root processes.
> >
> > The current policy dontaudit's the attempt to directly read /etc/shadow
> > to avoid noise.  When you did semodule -DB, you turned on that auditing.
> > But those denials are what is expected, and allowing them will mean
> > giving newrole direct read access to /etc/shadow (although that will
> > only work if running as root, of course, as otherwise it has to use a
> > suid helper like unix_chkpwd anyway).
> >
> > Does newrole work for you as a non-root user?
> 
> Okay, it looks like that unix_chkpwd is not allowed to read /etc/shadow when 
> running in newrole_t.
> 
> Here's the message:
> type=1400 audit(1217920543.235:26): avc: denied { read } for pid=1210 
> comm="unix_chkpwd" name="shadow" dev=dm-0 ino=29366926 
> scontext=staff_u:staff_r:newrole_t tcontext=system_u:object_r:shadow_t 
> tclass=file
> 
> Is it safe to add the rule suggested by audit2allow "allow newrole_t 
> shadow_t:file read;" to the policy or would there be a better way?
> 
> Wouldn't it in general be better if unix_chkpwd would transition into a domain 
> for itself which then in turn is allowed to access /etc/shadow?

unix_chkpwd is supposed to transition into its own domain already.  Is
it properly labeled (ls -Z /sbin/unix_chkpwd)?  It should have the
chkpwd_exec_t type.  And newrole_t should transition to the
system_chkpwd_t domain upon executing it.

-- 
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: Question about newrole

[Dennis Wronka]

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

On Tuesday 05 August 2008 23:36:40 Stephen Smalley wrote:
> On Tue, 2008-08-05 at 23:23 +0800, Dennis Wronka wrote:
> > On Tuesday 05 August 2008 22:48:55 Stephen Smalley wrote:
> > > On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
> > > > Thanks.
> > > > That seems to help quite a bit.
> > > > I now get some messages. For example it seems that newrole wants to
> > > > read /etc/shadow directly.
> > > > Will check those messages and play around with the policy.
> > >
> > > The way it works is that pam_unix attempts to open /etc/shadow directly
> > > for reading, and if it fails, it falls back to running unix_chkpwd to
> > > perform the password check.  SELinux policy prohibits most programs
> > > from directly reading /etc/shadow, including even ones that run as
> > > root, and forces them to go through unix_chkpwd instead, in order to
> > > limit the set of processes that have full read access to the shadow
> > > password file.
> > >
> > > The logic to try to open /etc/shadow and fall back to unix_chkpwd
> > > already existed before SELinux in order to support non-root processes
> > > re-authenticating the current user.  What changed with SELinux was that
> > > it could also happen for root processes.
> > >
> > > The current policy dontaudit's the attempt to directly read /etc/shadow
> > > to avoid noise.  When you did semodule -DB, you turned on that
> > > auditing. But those denials are what is expected, and allowing them
> > > will mean giving newrole direct read access to /etc/shadow (although
> > > that will only work if running as root, of course, as otherwise it has
> > > to use a suid helper like unix_chkpwd anyway).
> > >
> > > Does newrole work for you as a non-root user?
> >
> > Okay, it looks like that unix_chkpwd is not allowed to read /etc/shadow
> > when running in newrole_t.
> >
> > Here's the message:
> > type=1400 audit(1217920543.235:26): avc: denied { read } for pid=1210
> > comm="unix_chkpwd" name="shadow" dev=dm-0 ino=29366926
> > scontext=staff_u:staff_r:newrole_t tcontext=system_u:object_r:shadow_t
> > tclass=file
> >
> > Is it safe to add the rule suggested by audit2allow "allow newrole_t
> > shadow_t:file read;" to the policy or would there be a better way?
> >
> > Wouldn't it in general be better if unix_chkpwd would transition into a
> > domain for itself which then in turn is allowed to access /etc/shadow?
>
> unix_chkpwd is supposed to transition into its own domain already.  Is
> it properly labeled (ls -Z /sbin/unix_chkpwd)?  It should have the
> chkpwd_exec_t type.  And newrole_t should transition to the
> system_chkpwd_t domain upon executing it.

Thanks Stephen, that was the magic hint I believe.
My unix_chkpwd and unix_update were still in the position they got put by the 
PAM-installation (gotta check the install-script if there's a way to put them 
directly into /sbin). I moved them over, checked with restorecon and now it 
works.
Just had to put symlinks back to the original place because otherwise login 
didn't work. Will have to check if I really need these symlinks or if I can 
do without (Fedora 9 seems to get along without, so there must be a way for 
me to do it too).

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

Re: Question about newrole

[Justin Mattock]

On Tue, Aug 5, 2008 at 8:46 AM, Dennis Wronka <linuxweb@gmx.net> wrote:
> On Tuesday 05 August 2008 23:36:40 Stephen Smalley wrote:
>> On Tue, 2008-08-05 at 23:23 +0800, Dennis Wronka wrote:
>> > On Tuesday 05 August 2008 22:48:55 Stephen Smalley wrote:
>> > > On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
>> > > > Thanks.
>> > > > That seems to help quite a bit.
>> > > > I now get some messages. For example it seems that newrole wants to
>> > > > read /etc/shadow directly.
>> > > > Will check those messages and play around with the policy.
>> > >
>> > > The way it works is that pam_unix attempts to open /etc/shadow directly
>> > > for reading, and if it fails, it falls back to running unix_chkpwd to
>> > > perform the password check.  SELinux policy prohibits most programs
>> > > from directly reading /etc/shadow, including even ones that run as
>> > > root, and forces them to go through unix_chkpwd instead, in order to
>> > > limit the set of processes that have full read access to the shadow
>> > > password file.
>> > >
>> > > The logic to try to open /etc/shadow and fall back to unix_chkpwd
>> > > already existed before SELinux in order to support non-root processes
>> > > re-authenticating the current user.  What changed with SELinux was that
>> > > it could also happen for root processes.
>> > >
>> > > The current policy dontaudit's the attempt to directly read /etc/shadow
>> > > to avoid noise.  When you did semodule -DB, you turned on that
>> > > auditing. But those denials are what is expected, and allowing them
>> > > will mean giving newrole direct read access to /etc/shadow (although
>> > > that will only work if running as root, of course, as otherwise it has
>> > > to use a suid helper like unix_chkpwd anyway).
>> > >
>> > > Does newrole work for you as a non-root user?
>> >
>> > Okay, it looks like that unix_chkpwd is not allowed to read /etc/shadow
>> > when running in newrole_t.
>> >
>> > Here's the message:
>> > type=1400 audit(1217920543.235:26): avc: denied { read } for pid=1210
>> > comm="unix_chkpwd" name="shadow" dev=dm-0 ino=29366926
>> > scontext=staff_u:staff_r:newrole_t tcontext=system_u:object_r:shadow_t
>> > tclass=file
>> >
>> > Is it safe to add the rule suggested by audit2allow "allow newrole_t
>> > shadow_t:file read;" to the policy or would there be a better way?
>> >
>> > Wouldn't it in general be better if unix_chkpwd would transition into a
>> > domain for itself which then in turn is allowed to access /etc/shadow?
>>
>> unix_chkpwd is supposed to transition into its own domain already.  Is
>> it properly labeled (ls -Z /sbin/unix_chkpwd)?  It should have the
>> chkpwd_exec_t type.  And newrole_t should transition to the
>> system_chkpwd_t domain upon executing it.
>
> Thanks Stephen, that was the magic hint I believe.
> My unix_chkpwd and unix_update were still in the position they got put by the
> PAM-installation (gotta check the install-script if there's a way to put them
> directly into /sbin). I moved them over, checked with restorecon and now it
> works.
> Just had to put symlinks back to the original place because otherwise login
> didn't work. Will have to check if I really need these symlinks or if I can
> do without (Fedora 9 seems to get along without, so there must be a way for
> me to do it too).
>

Cool, glad to see you're up and running.

-- 
Justin P. Mattock

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