SystemsSec 2016W Lecture 6 - Revision history

Miranmirza at 13:42, 4 February 2016

2016-02-04T13:42:06Z

← Older revision		Revision as of 13:42, 4 February 2016
Line 24:		Line 24:
	Diagram detailing the separation of root into three roots.		Diagram detailing the separation of root into three roots.

	[[File:DiagramOS.png]]		[[File:DiagramOS.png]]<br>
			''Diagram detailing the separation of root into three roots''

	'''The Danger of Root'''		'''The Danger of Root'''

Miranmirza at 13:40, 4 February 2016

2016-02-04T13:40:50Z

← Older revision		Revision as of 13:40, 4 February 2016
Line 24:		Line 24:
	Diagram detailing the separation of root into three roots.		Diagram detailing the separation of root into three roots.

			[[File:DiagramOS.png]]

	'''The Danger of Root'''		'''The Danger of Root'''

Miranmirza at 13:40, 4 February 2016

2016-02-04T13:40:19Z

← Older revision		Revision as of 13:40, 4 February 2016
Line 1:		Line 1:
	'''Topics'''		'''Topics & Readings'''
	*Ethical Hacking		*Ethical Hacking
	*Security mechanisms in operating systems		*Security mechanisms in operating systems
Line 34:		Line 34:
	To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?		To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?

	Conclusions~~: almost~~ everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don't know how to do it, but it's because we don't want to commit to the correct way of doing things which is why it's all ugly, it's like Xwindow which draws windows and elements but delegates the elements to the operating system.		'''Conclusions'''

			Almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don't know how to do it, but it's because we don't want to commit to the correct way of doing things which is why it's all ugly, it's like Xwindow which draws windows and elements but delegates the elements to the operating system.

Miranmirza at 04:23, 4 February 2016

2016-02-04T04:23:48Z

← Older revision	Revision as of 04:23, 4 February 2016
Line 1:	Line 1:
		'''Topics'''
		*Ethical Hacking
		*Security mechanisms in operating systems
		*Danger of root


		'''Ethical Hacking'''

		''Red team'': when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.
		''Blue team'': defence team.

		The naming convention comes from US politics where the red team gets it's name from the 'evil' communists and blue represents the 'good' Americans.
		Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.

		A separate question:
		How much does this actually improve security?
		The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur.
		But do actual people doing ethical hacking on software actually improve software then?

		'''Security mechanisms in operating systems'''

		MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.
		The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)
		Diagram detailing the separation of root into three roots.



		'''The Danger of Root'''

		Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.
		We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.

		We need even finer grain control though, however most software developers don't want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.
		To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?

		Conclusions: almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don't know how to do it, but it's because we don't want to commit to the correct way of doing things which is why it's all ugly, it's like Xwindow which draws windows and elements but delegates the elements to the operating system.

Miranmirza: Blanked the page

2016-02-04T04:05:23Z

Blanked the page

← Older revision		Revision as of 04:05, 4 February 2016
Line 1:		Line 1:
	~~'''Topics & Readings'''~~
	*Ethical Hacking
	*Security mechanisms in operating systems
	*Danger of root


	~~'''Ethical Hacking'''~~

	~~''Red team'': when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.~~
	~~''Blue team'': defence team.~~

	~~The naming convention comes from US politics where the red team gets it's name from the 'evil' communists and blue represents the 'good' Americans.~~
	Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.

	~~A separate question:~~
	~~How much does this actually improve security?~~
	~~The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur.~~
	~~But do actual people doing ethical hacking on software actually improve software then?~~

	~~'''Security mechanisms in operating systems'''~~

	MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.
	~~The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)~~
	~~Diagram detailing the separation of root into three roots.~~



	~~'''The Danger of Root'''~~

	Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.
	We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.

	We need even finer grain control though, however most software developers don't want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.
	To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?

	Conclusions: almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don't know how to do it, but it's because we don't want to commit to the correct way of doing things which is why it's all ugly, it's like Xwindow which draws windows and elements but delegates the elements to the operating system.

Miranmirza: Created page with "'''Topics & Readings''' Ethical Hacking Security mechanisms in operating systems *Danger of root '''Ethical Hacking''' ''Red team'': when you hire a team to formally eval..."

2016-02-04T04:05:04Z

Created page with "'''Topics & Readings''' *Ethical Hacking *Security mechanisms in operating systems *Danger of root '''Ethical Hacking''' ''Red team'': when you hire a team to formally eval..."

New page

'''Topics & Readings'''
*Ethical Hacking
*Security mechanisms in operating systems
*Danger of root

'''Ethical Hacking'''

''Red team'': when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.
''Blue team'': defence team.

The naming convention comes from US politics where the red team gets it's name from the 'evil' communists and blue represents the 'good' Americans.
Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.

A separate question:
How much does this actually improve security?
The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur.
But do actual people doing ethical hacking on software actually improve software then?

'''Security mechanisms in operating systems'''

MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.
The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)
Diagram detailing the separation of root into three roots.

'''The Danger of Root'''

Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.
We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.

We need even finer grain control though, however most software developers don't want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.
To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?

Conclusions: almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don't know how to do it, but it's because we don't want to commit to the correct way of doing things which is why it's all ugly, it's like Xwindow which draws windows and elements but delegates the elements to the operating system.

SystemsSec 2016W Lecture 6 - Revision history

Miranmirza at 13:42, 4 February 2016

Miranmirza at 13:40, 4 February 2016

Miranmirza at 13:40, 4 February 2016

Miranmirza at 04:23, 4 February 2016

Miranmirza: Blanked the page

Miranmirza: Created page with "'''Topics & Readings''' *Ethical Hacking *Security mechanisms in operating systems *Danger of root '''Ethical Hacking''' ''Red team'': when you hire a team to formally eval..."

Miranmirza: Created page with "'''Topics & Readings''' Ethical Hacking Security mechanisms in operating systems *Danger of root '''Ethical Hacking''' ''Red team'': when you hire a team to formally eval..."