dear all, can you please point me to the right place: with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the samba vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a SELinux system, and finding out what the attacker can do and cannot do in the case of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to read/manipulate the user's home directories. But what about the rest? What other things can an end user (who is not very experienced in SELinux) examine to know what the attacker can / cannot do?
thank you
To refine my questions in the earlier email: 1) many of the things the attacker can do if he exploits the Samba vulnerability can be found in the source policy. but there are also so many other rules in the policy (hundreds?), my question is how do I know if the other rules matter much? there are >300 rules related to smbd_t, and it just *seems* a lot can go wrong with the system.
2) how do we verify the part about what the attackers cannot do? does it mean, if i cannot find a rule that links smbd_t with user_home_t with the 'read' permission, the attacker cannot read/manipulate user home directories? Or it is not as trivial?
3) i am assuming ports 137-139 and 445 are labelled smbd_port_t, but where can i find this assignment in the policy? i am currently using apol.
thank you
On Mon, Aug 17, 2009 at 10:42 AM, adrian golding adriangolding@gmail.comwrote:
dear all, can you please point me to the right place: with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the samba vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a SELinux system, and finding out what the attacker can do and cannot do in the case of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to read/manipulate the user's home directories. But what about the rest? What other things can an end user (who is not very experienced in SELinux) examine to know what the attacker can / cannot do?
thank you
On Mon, 17 Aug 2009 13:05:53 +0800 adrian golding adriangolding@gmail.com wrote:
To refine my questions in the earlier email:
- i am assuming ports 137-139 and 445 are labelled smbd_port_t, but
where can i find this assignment in the policy? i am currently using apol.
I don't have the knowledge required to answer all of your questions - in fact, I also would like to hear what some of the more informed members on this list think about what you've raised.
But, to find the ports for smbd_port_t, you can do as root:
semanage port -l | grep smbd
Cheers,
On 08/17/2009 01:05 AM, adrian golding wrote:
To refine my questions in the earlier email:
- many of the things the attacker can do if he exploits the Samba
vulnerability can be found in the source policy. but there are also so many other rules in the policy (hundreds?), my question is how do I know if the other rules matter much? there are >300 rules related to smbd_t, and it just *seems* a lot can go wrong with the system.
Yes you got to ask the questions. You can ask a question in APOL about whether the smbd_t can read a file.
A simple query sesearch --allow -s smbd_t -t user_home_t -c file -p read
asks whether smbd_t can read files labeled user_home_t directly. You can use apol to look for transition rules that might allow it.
SELinux is all about types so you need to user commands like
semanage port -l
To list the types that ports are assigned to or /etc/selinux/targeted/context/files/files.context to see what types are assigned to files, by default.
- how do we verify the part about what the attackers cannot do? does it
mean, if i cannot find a rule that links smbd_t with user_home_t with the 'read' permission, the attacker cannot read/manipulate user home directories? Or it is not as trivial?
Anything that is not allowed is denied. See above.
- i am assuming ports 137-139 and 445 are labelled smbd_port_t, but where
can i find this assignment in the policy? i am currently using apol.
semanage port -l
thank you
On Mon, Aug 17, 2009 at 10:42 AM, adrian golding adriangolding@gmail.comwrote:
dear all, can you please point me to the right place: with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the samba vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a SELinux system, and finding out what the attacker can do and cannot do in the case of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to read/manipulate the user's home directories. But what about the rest? What other things can an end user (who is not very experienced in SELinux) examine to know what the attacker can / cannot do?
thank you
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
dear all, thank you for the comments/tips. The reason for asking these questions is that although i think SELinux is good in many ways, eg, it allows the implementation of RBAC and MAC and such, and yes indeed, we can use tools like APOL's domain analysis to find out if one domain can 'reach' another domain, but the right questions have to be asked. Maybe this is too far fetched, but if a paranoid administrator wants to fully know what is at risk before deploying the system, would it be a good practice to generate some domain reachability tree for each of the services that is facing the Internet / network?
Or another way for this paranoid administrator is to use a strict policy (instead of targeted) and manually every rule, which is only manageable if the machine is having a very specific function like a firewall or file server?
thank you..
On Wed, Aug 19, 2009 at 5:49 AM, Daniel J Walsh dwalsh@redhat.com wrote:
On 08/17/2009 01:05 AM, adrian golding wrote:
To refine my questions in the earlier email:
- many of the things the attacker can do if he exploits the Samba
vulnerability can be found in the source policy. but there are also so
many
other rules in the policy (hundreds?), my question is how do I know if
the
other rules matter much? there are >300 rules related to smbd_t, and it just *seems* a lot can go wrong with the system.
Yes you got to ask the questions. You can ask a question in APOL about whether the smbd_t can read a file.
A simple query sesearch --allow -s smbd_t -t user_home_t -c file -p read
asks whether smbd_t can read files labeled user_home_t directly. You can use apol to look for transition rules that might allow it.
SELinux is all about types so you need to user commands like
semanage port -l
To list the types that ports are assigned to or /etc/selinux/targeted/context/files/files.context to see what types are assigned to files, by default.
- how do we verify the part about what the attackers cannot do? does it
mean, if i cannot find a rule that links smbd_t with user_home_t with the 'read' permission, the attacker cannot read/manipulate user home directories? Or it is not as trivial?
Anything that is not allowed is denied. See above.
- i am assuming ports 137-139 and 445 are labelled smbd_port_t, but
where
can i find this assignment in the policy? i am currently using apol.
semanage port -l
thank you
On Mon, Aug 17, 2009 at 10:42 AM, adrian golding <
adriangolding@gmail.com>wrote:
dear all, can you please point me to the right place: with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the
samba
vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a
SELinux
system, and finding out what the attacker can do and cannot do in the
case
of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to
read/manipulate
the user's home directories. But what about the rest? What other things
can
an end user (who is not very experienced in SELinux) examine to know
what
the attacker can / cannot do?
thank you
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On 08/19/2009 02:28 AM, adrian golding wrote:
dear all, thank you for the comments/tips. The reason for asking these questions is that although i think SELinux is good in many ways, eg, it allows the implementation of RBAC and MAC and such, and yes indeed, we can use tools like APOL's domain analysis to find out if one domain can 'reach' another domain, but the right questions have to be asked. Maybe this is too far fetched, but if a paranoid administrator wants to fully know what is at risk before deploying the system, would it be a good practice to generate some domain reachability tree for each of the services that is facing the Internet / network?
Or another way for this paranoid administrator is to use a strict policy (instead of targeted) and manually every rule, which is only manageable if the machine is having a very specific function like a firewall or file server?
thank you..
On Wed, Aug 19, 2009 at 5:49 AM, Daniel J Walsh dwalsh@redhat.com wrote:
On 08/17/2009 01:05 AM, adrian golding wrote:
To refine my questions in the earlier email:
- many of the things the attacker can do if he exploits the Samba
vulnerability can be found in the source policy. but there are also so
many
other rules in the policy (hundreds?), my question is how do I know if
the
other rules matter much? there are >300 rules related to smbd_t, and it just *seems* a lot can go wrong with the system.
Yes you got to ask the questions. You can ask a question in APOL about whether the smbd_t can read a file.
A simple query sesearch --allow -s smbd_t -t user_home_t -c file -p read
asks whether smbd_t can read files labeled user_home_t directly. You can use apol to look for transition rules that might allow it.
SELinux is all about types so you need to user commands like
semanage port -l
To list the types that ports are assigned to or /etc/selinux/targeted/context/files/files.context to see what types are assigned to files, by default.
- how do we verify the part about what the attackers cannot do? does it
mean, if i cannot find a rule that links smbd_t with user_home_t with the 'read' permission, the attacker cannot read/manipulate user home directories? Or it is not as trivial?
Anything that is not allowed is denied. See above.
- i am assuming ports 137-139 and 445 are labelled smbd_port_t, but
where
can i find this assignment in the policy? i am currently using apol.
semanage port -l
thank you
On Mon, Aug 17, 2009 at 10:42 AM, adrian golding <
adriangolding@gmail.com>wrote:
dear all, can you please point me to the right place: with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the
samba
vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a
SELinux
system, and finding out what the attacker can do and cannot do in the
case
of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to
read/manipulate
the user's home directories. But what about the rest? What other things
can
an end user (who is not very experienced in SELinux) examine to know
what
the attacker can / cannot do?
thank you
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
There is very little differnce in RHEL5 and beyond between strict policy and targeted.
In targeted policy there are several unconfined domains. So an administrator would want to make sure there are no or few processes running on his system labeled initrc_t, inetd_child_t or unoconfined_t for example.
But from a network facing point of view targeted and strict provide the same inforcement.
In Fedora 10/11/Rawhide, strict policy has dissapeared, and you can remove the unconfined module to get the same functionality that used to be in strict policy.
On Mon, 2009-08-17 at 10:42 +0800, adrian golding wrote:
dear all, can you please point me to the right place:
with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the samba vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a SELinux system, and finding out what the attacker can do and cannot do in the case of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to read/manipulate the user's home directories. But what about the rest? What other things can an end user (who is not very experienced in SELinux) examine to know what the attacker can / cannot do?
sesearch can be a very useful tool for interrogating the policy to see what a given domain can access, and the information flow and domain transition analysis capabilities of apol are likewise quite useful.
On Mon, Aug 17, 2009 at 12:28:02PM +0000, Stephen Smalley wrote:
On Mon, 2009-08-17 at 10:42 +0800, adrian golding wrote:
dear all, can you please point me to the right place:
with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the samba vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a SELinux system, and finding out what the attacker can do and cannot do in the case of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to read/manipulate the user's home directories. But what about the rest? What other things can an end user (who is not very experienced in SELinux) examine to know what the attacker can / cannot do?
sesearch can be a very useful tool for interrogating the policy to see what a given domain can access, and the information flow and domain transition analysis capabilities of apol are likewise quite useful.
With regard to sesearch it is good to know that it displays all rules, also the rules that maybe disabled by boolean. So with that in mind sesearch can be a bit misleading.
if you encounter a situation where access is denied, but where sesearch returns a rule that would have allowed the access, then pipe the avc denial into audit2why.
-- Stephen Smalley National Security Agency
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On 08/17/2009 08:33 AM, Dominick Grift wrote:
On Mon, Aug 17, 2009 at 12:28:02PM +0000, Stephen Smalley wrote:
On Mon, 2009-08-17 at 10:42 +0800, adrian golding wrote:
dear all, can you please point me to the right place:
with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the samba vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a SELinux system, and finding out what the attacker can do and cannot do in the case of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to read/manipulate the user's home directories. But what about the rest? What other things can an end user (who is not very experienced in SELinux) examine to know what the attacker can / cannot do?
sesearch can be a very useful tool for interrogating the policy to see what a given domain can access, and the information flow and domain transition analysis capabilities of apol are likewise quite useful.
With regard to sesearch it is good to know that it displays all rules, also the rules that maybe disabled by boolean. So with that in mind sesearch can be a bit misleading.
if you encounter a situation where access is denied, but where sesearch returns a rule that would have allowed the access, then pipe the avc denial into audit2why.
-- Stephen Smalley National Security Agency
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
If you use the -C option it will show you the boolean. Of course it will not tell you if it is enabled or not.
On 08/16/2009 10:42 PM, adrian golding wrote:
dear all, can you please point me to the right place: with reference to: http://danwalsh.livejournal.com/10131.html
i am interested in how dan knows what an attacker can make use of the samba vulnerability to do by default, and what the attacker cannot do. More generally speaking, how do we look at a service or application in a SELinux system, and finding out what the attacker can do and cannot do in the case of the service being exploited?
in that page, he looked at some of the relevant booleans and i guess "samba_enable_home_dirs ---> off" prevents the attacker to read/manipulate the user's home directories. But what about the rest? What other things can an end user (who is not very experienced in SELinux) examine to know what the attacker can / cannot do?
thank you
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
One simple answer is I can look at the policy source code.
Secondly you can use the sesearch command
sesearch --allow -s smbd_t
Shows me all the rules of what smbd_t is allowed to do. If I want to do more complex analyses of the policy I can use a tool like apol.
selinux@lists.fedoraproject.org