SystemsSec 2018W Lecture 4 - Revision history

Soma at 06:54, 30 January 2018

2018-01-30T06:54:33Z

← Older revision		Revision as of 06:54, 30 January 2018
Line 1:		Line 1:
			==Audio==

			[http://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/lectures/comp4108-2018w-lec04-17Jan2018.m4a Lecture 4 Audio]




	==Notes==		==Notes==

Soma at 06:53, 30 January 2018

2018-01-30T06:53:51Z

← Older revision		Revision as of 06:53, 30 January 2018
Line 1:		Line 1:
	~~= Notes =~~

	~~Today we discussed psswd as a way of touching on a number of security topics~~

	== passwd ==



			==Notes==

			Today we discussed passwd as a way of touching on a number of security topics

			===passwd===

	*the linux program for modifying a user password		*the linux program for modifying a user password
Line 12:		Line 18:
	*on more modern systems, this is split into /etc/passwd and /etc/shadow		*on more modern systems, this is split into /etc/passwd and /etc/shadow
	*root owns the file		*root owns the file
	*in order to modify the password, the program needs root ~~priveleges~~ in the classic model		*in order to modify the password, the program needs root privileges in the classic model
	**this gives the program the ability to modify any file on the system		**this gives the program the ability to modify any file on the system


	=== the setuid bit ===		===the setuid bit===
	*every process has a user id (uid) and a group id (gid). Every file has bits that set the permissions for the users and groups associated with it.		*every process has a user id (uid) and a group id (gid). Every file has bits that set the permissions for the users and groups associated with it.
	*in addition to the classic read, write and execute (rwx) for the uid and gid, there are also setuid and setgid (s) bits		*in addition to the classic read, write and execute (rwx) for the uid and gid, there are also setuid and setgid (s) bits
	*without the set bit, when a new process is created, execv loads the new process, but the uid and gid don't change.		*without the set bit, when a new process is created, execv loads the new process, but the uid and gid don't change.
	*setuid bit allows the new process to be created with a new uid (effective uid). It runs with the ~~priveleges~~ associated with the new uid.		*setuid bit allows the new process to be created with a new uid (effective uid). It runs with the privileges associated with the new uid.

	if a process has an effective uid of root, it can do basically anything to the system (the all powerful root model)		if a process has an effective uid of root, it can do basically anything to the system (the all powerful root model)
Line 37:		Line 43:
	how could we make the process less dangerous?		how could we make the process less dangerous?

	could we run it without full root ~~priveleges~~?		could we run it without full root privileges?

	we are going to have this binary. It will have root ~~priveleges~~, it will have full control.		we are going to have this binary. It will have root privileges, it will have full control.
	*how to we protect ourselves? what measures can we take?		*how to we protect ourselves? what measures can we take?
	**limit the scope of our mistakes		**limit the scope of our mistakes
	***limit the time that you have the dangerous ~~priveleges~~		***limit the time that you have the dangerous privileges
	***limit the ~~priveleges~~		***limit the privileges
	***ideally audit to make sure that the ~~priveleges~~ were used appropriately.		***ideally audit to make sure that the privileges were used appropriately.

	Just knowing about basic mechanisms, what could we do?		Just knowing about basic mechanisms, what could we do?
	*separate the part of the program that needs ~~priveleges~~ from the parts that don't.		*separate the part of the program that needs privileges from the parts that don't.
	*analyzing user input is the most dangerous part, and should be separated as much as possible from parts of the program with powerful ~~privegeles~~		*analyzing user input is the most dangerous part, and should be separated as much as possible from parts of the program with powerful privileges
	**~~malious~~ input attacks		**malicious input attacks

	passwd is one of the simplest examples, and it touched on a number of topis:		passwd is one of the simplest examples, and it touched on a number of topis:
	*access control		*access control
	*(least) ~~privelege~~ (time and space)		*(least) privilege (time and space)
	**for passwd, this can be a problem because there ~~isa~~ file with everyone's password information. In order to change this file, you need root ~~priveleges~~.		**for passwd, this can be a problem because there is a file with everyone's password information. In order to change this file, you need root privileges.
	***Could you change that basic premise? You would have to split it out so that everyone had there own separate passwd files. This could cause problems for legacy software, and		***Could you change that basic premise? You would have to split it out so that everyone had there own separate passwd files. This could cause problems for legacy software, and

Line 67:		Line 73:
	*kernel mechanisms		*kernel mechanisms
	**the setuid bit		**the setuid bit
	**if you have ~~priveleges~~, they were usually granted by the kernel		**if you have privileges, they were usually granted by the kernel
	*other attacks		*other attacks
	**breaking the hash		**breaking the hash

	== Similar problems ==		===Similar problems===

	*What other command line tools have similar security issues?		*What other command line tools have similar security issues?
Line 84:		Line 90:

	Determining access by users and groups is coarse.		Determining access by users and groups is coarse.
	*root is a collection of ~~priveleges~~		*root is a collection of privileges
	**could we have a subset of these ~~priveleges~~?		**could we have a subset of these privileges?
	*~~capababilities~~		*capabilities
	**a ~~differnt~~ way of thinking about access control		**a different way of thinking about access control
	**you can drop capabilities that you don't need.		**you can drop capabilities that you don't need.
	**however, some ~~capabilies~~ are still very powerful, ie modify files or modify devices		**however, some capabilities are still very powerful, i.e. modify files or modify devices
	*there are more complex mechanism for access control and privileges, but they often aren't used. In order for something to be used effectively, it needs to be understandable to		*there are more complex mechanism for access control and privileges, but they often aren't used. In order for something to be used effectively, it needs to be understandable to

	people using it. Simple mechanisms remain widely used.		people using it. Simple mechanisms remain widely used.

	== Exercises ==		===Exercises===
	Two ~~exercies~~ will be posted:		Two exercises will be posted:
	*Write your own version of passwd		*Write your own version of passwd
	**any language		**any language
	**setuid root and change password		**setuid root and change password
	**think through the features and the implementation, and she security issues ~~tha~~ arise.		**think through the features and the implementation, and she security issues that arise.
	**process input carefully and drop ~~unneccessary privelegs~~.		**process input carefully and drop unnecessary privilegs.
	**for the write up, not looking for documentation about perfectly working code. what went wrong, what paths did you take, what issues did you have, what did you learn?		**for the write up, not looking for documentation about perfectly working code. what went wrong, what paths did you take, what issues did you have, what did you learn?
	*What ~~priveleges~~ are required for networking?		*What privileges are required for networking?
	**what operations require higher ~~priveleges~~.		**what operations require higher privileges.
	**at first distinction, it may seems simple (users can use the network, root can modify)		**at first distinction, it may seems simple (users can use the network, root can modify)
	***however it is more complex. Can an application set up connection to a new wifi access point?		***however it is more complex. Can an application set up connection to a new wifi access point?

	If you have any ideas for exercises, feel free to discuss them in slack		If you have any ideas for exercises, feel free to discuss them in slack

Trent: Notes from class, first draft

2018-01-17T18:16:42Z

Notes from class, first draft

New page

= Notes =

Today we discussed psswd as a way of touching on a number of security topics

== passwd ==

*the linux program for modifying a user password
*seems like a simple program, but has a number of features that could present a security concern.
*where are they stored?
*used to be in one file, including the hashed passwords (/etc/passwd)
*problem is that data in that if attackers can read the hashes, the hash can be cracked.
*on more modern systems, this is split into /etc/passwd and /etc/shadow
*root owns the file
*in order to modify the password, the program needs root priveleges in the classic model
**this gives the program the ability to modify any file on the system

=== the setuid bit ===
*every process has a user id (uid) and a group id (gid). Every file has bits that set the permissions for the users and groups associated with it.
*in addition to the classic read, write and execute (rwx) for the uid and gid, there are also setuid and setgid (s) bits
*without the set bit, when a new process is created, execv loads the new process, but the uid and gid don't change.
*setuid bit allows the new process to be created with a new uid (effective uid). It runs with the priveleges associated with the new uid.

if a process has an effective uid of root, it can do basically anything to the system (the all powerful root model)

for a program like passwd, it may seem very simple, but it does lots of things, including things that might make the system vulnerable to attack.

*attack?
**the chroot option lets you change the etc/passwd for a subdirectory
**by using a symlink to a different file, you could take control of the system

in general, '''flexibility is the enemy of security'''
*more functionality means more corner cases, and more things that you haven't thought about.

how could we make the process less dangerous?

could we run it without full root priveleges?

we are going to have this binary. It will have root priveleges, it will have full control.
*how to we protect ourselves? what measures can we take?
**limit the scope of our mistakes
***limit the time that you have the dangerous priveleges
***limit the priveleges
***ideally audit to make sure that the priveleges were used appropriately.

Just knowing about basic mechanisms, what could we do?
*separate the part of the program that needs priveleges from the parts that don't.
*analyzing user input is the most dangerous part, and should be separated as much as possible from parts of the program with powerful privegeles
**malious input attacks

passwd is one of the simplest examples, and it touched on a number of topis:
*access control
*(least) privelege (time and space)
**for passwd, this can be a problem because there isa file with everyone's password information. In order to change this file, you need root priveleges.
***Could you change that basic premise? You would have to split it out so that everyone had there own separate passwd files. This could cause problems for legacy software, and

could even open up other potential security vulnerabilities.
*unsanitized input
**not all input is trusted. This what programs do: they process data.
*trust
**trust is hard.
**in computer security, trusted means that if it betrays you, it can hurt you.
**trust can be limited.
**like with people, applications should behave differently towards trusted and untrusted inputs
*kernel mechanisms
**the setuid bit
**if you have priveleges, they were usually granted by the kernel
*other attacks
**breaking the hash

== Similar problems ==

*What other command line tools have similar security issues?
**anything with the setuid bit, executables that run as other users.
*what binaries have setuid root?
**mount
**fuse
**cron
***for scheduling tasks.
**sudo
**ping

Determining access by users and groups is coarse.
*root is a collection of priveleges
**could we have a subset of these priveleges?
*capababilities
**a differnt way of thinking about access control
**you can drop capabilities that you don't need.
**however, some capabilies are still very powerful, ie modify files or modify devices
*there are more complex mechanism for access control and privileges, but they often aren't used. In order for something to be used effectively, it needs to be understandable to

people using it. Simple mechanisms remain widely used.

== Exercises ==
Two exercies will be posted:
*Write your own version of passwd
**any language
**setuid root and change password
**think through the features and the implementation, and she security issues tha arise.
**process input carefully and drop unneccessary privelegs.
**for the write up, not looking for documentation about perfectly working code. what went wrong, what paths did you take, what issues did you have, what did you learn?
*What priveleges are required for networking?
**what operations require higher priveleges.
**at first distinction, it may seems simple (users can use the network, root can modify)
***however it is more complex. Can an application set up connection to a new wifi access point?

If you have any ideas for exercises, feel free to discuss them in slack