9:47 p.m.
Dear Folks,
I have written a program that I use both run by Apache and by normal
users as a command line application.
When I changed the attribute of the program file to
httpd_sys_script_exec_t, It no longer had permission to write to the
console. What is the simplest way to handle this properly in SELinux?
--
Nick Urbanik RHCE http://nicku.org nicku(at)nicku.org
Proud ex-member of Dept. of Information & Communications Technology in
Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity
Award winner, programmed by ICT's own graduates!
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
10:07 p.m.
On Thu, 2005-01-20 at 14:47 +1100, Nick Urbanik wrote:
Dear Folks,
I have written a program that I use both run by Apache and by normal
users as a command line application.
When I changed the attribute of the program file to
httpd_sys_script_exec_t, It no longer had permission to write to the
console. What is the simplest way to handle this properly in SELinux?
The simplest solution is to simply make two copies of the program file
(by using e.g. cp), accessible by different names, with different
labels. So you'd have e.g. "/usr/bin/program.cgi" labeled as
httpd_sys_script_exec_t, and just "/usr/bin/program" labeled as bin_t.
The other solution is to define a new type, and grant both domains in
question access to it. This is a lot more complex; now you have to
consider potential information flow between the two domains which were
(presumably) separate before.
2:56 a.m.
Dear Folks,
On Wed, Jan 19, 2005 at 11:07:59PM -0500, Colin Walters wrote:
On Thu, 2005-01-20 at 14:47 +1100, Nick Urbanik wrote:
> Dear Folks,
>
> I have written a program that I use both run by Apache and by normal
> users as a command line application.
>
> When I changed the attribute of the program file to
> httpd_sys_script_exec_t, It no longer had permission to write to the
> console. What is the simplest way to handle this properly in SELinux?
The simplest solution is to simply make two copies of the program file
(by using e.g. cp), accessible by different names, with different
labels. So you'd have e.g. "/usr/bin/program.cgi" labeled as
httpd_sys_script_exec_t, and just "/usr/bin/program" labeled as
bin_t.
This raises a can of worms when maintaining the program, and the
question arises as to which is the "real one". I'm likely to forget
to update one or the other. "Which one do I enter into version
control?" is a question I would ask myself often.
Where are SELinux attributes stored? In the inode? If not, can hard
links be given different attributes?
The other solution is to define a new type, and grant both domains
in
question access to it. This is a lot more complex; now you have to
consider potential information flow between the two domains which were
(presumably) separate before.
Well, that may be more managable in the long term. Can you suggest a
(relatively) simple way of doing that?
--
Nick Urbanik RHCE http://nicku.org nicku(at)nicku.org
Proud ex-member of Dept. of Information & Communications Technology in
Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity
Award winner, programmed by ICT's own graduates!
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
9:47 a.m.
Nick Urbanik wrote:
Dear Folks,
On Wed, Jan 19, 2005 at 11:07:59PM -0500, Colin Walters wrote:
>On Thu, 2005-01-20 at 14:47 +1100, Nick Urbanik wrote:
>
>
>>Dear Folks,
>>
>>I have written a program that I use both run by Apache and by normal
>>users as a command line application.
>>
>>When I changed the attribute of the program file to
>>httpd_sys_script_exec_t, It no longer had permission to write to the
>>console. What is the simplest way to handle this properly in SELinux?
>>
>>
>The simplest solution is to simply make two copies of the program file
>(by using e.g. cp), accessible by different names, with different
>labels. So you'd have e.g. "/usr/bin/program.cgi" labeled as
>httpd_sys_script_exec_t, and just "/usr/bin/program" labeled as
>bin_t.
>
>
This raises a can of worms when maintaining the program, and the
question arises as to which is the "real one". I'm likely to forget
to update one or the other. "Which one do I enter into version
control?" is a question I would ask myself often.
Where are SELinux attributes stored? In the inode? If not, can hard
links be given different attributes?
>The other solution is to define a new type, and grant both domains in
>question access to it. This is a lot more complex; now you have to
>consider potential information flow between the two domains which were
>(presumably) separate before.
>
>
Well, that may be more managable in the long term. Can you suggest a
(relatively) simple way of doing that?
------------------------------------------------------------------------
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
This sounds like a bug. A user executing a httpd script should not be
changing context to httpd_sys_script_t, correct?
10:05 a.m.
On Thu, 2005-01-20 at 10:47 -0500, Daniel J Walsh wrote:
This sounds like a bug. A user executing a httpd script should not
be
changing context to httpd_sys_script_t, correct?
There's an explicit rule for this now, in
macros/program/apache_macros.te:
ifelse($1, sys, `
#
# If a user starts a script by hand it gets the proper context
#
domain_auto_trans(sysadm_t, httpd_$1_script_exec_t, httpd_$1_script_t)
role sysadm_r types httpd_$1_script_t;
', `
# If a user starts a script by hand it gets the proper context
domain_auto_trans($1_t, httpd_$1_script_exec_t, httpd_$1_script_t)
role $1_r types httpd_$1_script_t;
We probably want to just drop this in targeted policy. In strict, we
grant userdomains access to all the derived types such as
httpd_sys_content_t, so not doing the transition (i.e. just changing it
to can_exec, or maybe domain_trans) should allow the CGI script to
continue to work, at first glance. But I have a feeling there was a
particular reason policy has this rule; clearly it was intentional.
I'll think about this for a bit.
9:52 a.m.
On Thu, 2005-01-20 at 19:56 +1100, Nick Urbanik wrote:
This raises a can of worms when maintaining the program, and the
question arises as to which is the "real one".
Well...no, since you still have the same source code and build process,
etc. This solution is a lot like what pre-SELinux chroot scripts did
for bind, etc.
I'm likely to forget
to update one or the other.
I'd imagine that your Makefile or whatever would install the two copies
explicitly. Or you could do it in the RPM build process.
"Which one do I enter into version
control?" is a question I would ask myself often.
You enter binaries into version control?
Where are SELinux attributes stored? In the inode?
They are tightly coupled to the inode, yes. Just like Unix permissions
are.
If not, can hard
links be given different attributes?
No; hard links are just additional names for the same object. SELinux
protects the actual object, not names or references to objects.
> The other solution is to define a new type, and grant both
domains in
> question access to it. This is a lot more complex; now you have to
> consider potential information flow between the two domains which were
> (presumably) separate before.
Well, that may be more managable in the long term. Can you suggest a
(relatively) simple way of doing that?
You'd have to explain more about your setup. Are you just trying to run
the CGI script as an ordinary user from unconfined_t?
2:50 p.m.
Colin Walters wrote:
On Thu, 2005-01-20 at 19:56 +1100, Nick Urbanik wrote:
>This raises a can of worms when maintaining the program, and the
>question arises as to which is the "real one".
>
>
Well...no, since you still have the same source code and build process,
etc. This solution is a lot like what pre-SELinux chroot scripts did
for bind, etc.
> I'm likely to forget
>to update one or the other.
>
>
I'd imagine that your Makefile or whatever would install the two copies
explicitly. Or you could do it in the RPM build process.
>"Which one do I enter into version
>control?" is a question I would ask myself often.
>
>
You enter binaries into version control?
>Where are SELinux attributes stored? In the inode?
>
>
They are tightly coupled to the inode, yes. Just like Unix permissions
are.
>If not, can hard
>links be given different attributes?
>
>
No; hard links are just additional names for the same object. SELinux
protects the actual object, not names or references to objects.
>>The other solution is to define a new type, and grant both domains in
>>question access to it. This is a lot more complex; now you have to
>>consider potential information flow between the two domains which were
>>(presumably) separate before.
>>
>>
>Well, that may be more managable in the long term. Can you suggest a
>(relatively) simple way of doing that?
>
>
You'd have to explain more about your setup. Are you just trying to run
the CGI script as an ordinary user from unconfined_t?
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
After thinking about it, I think preserving file context would be the
problem. So a different solution, might
be to take advantage of the http_tty_comm boolean and turn on access to
it from httpd_$$$_script_t so if an
admin or an unconfined_t process ran the script it would be able to
output to the terminal.
Dan
7033
days inactive
7033
days old
selinux@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Colin Walters -
Daniel J Walsh -
Nick Urbanik